[SIPForum-techwg] (Interop) SHOULD in RFCs...

[Peter Musgrave]

Hi Syed, 

 

I favor the idea of SIPConnect profiles, starting with a "vanilla
telephony" once. 

 

So it would seem that step one in defining a basic level of interop
use-cases would be to:

1)     List some basic use cases

2)     Determine how these are affected by spec. interpretations of
SHOULD and clarify those which impact the use case and publish this
profile as part of SIPForum.

 

I think the important thing is to get a basic level of interop nailed
down so there are actual implementations which can say they support
SIPConnect and proof of interop is established between a handful of
implementations. 

 

Peter

 

________________________________

From: Ahmad, Syed [mailto:Syed.Ahmad at eu.panasonic.com] 
Sent: Monday, April 23, 2007 9:39 AM
To: Peter Musgrave; techwg at sipforum.org
Subject: RE: [SIPForum-techwg] (Interop) SHOULD in RFCs...

 

Peter,

 

Excellent point.

 

May be:

Learn from how Bluetooth is handled with various Spec profile support
(http://www.bluetooth.com/Bluetooth/Learn/Works/Profiles_Overview.htm)

Problem: Too many profiles (although some profiles are part of a group
of profiles - so may be not so bad after all).

 

Learn from how Java is handled with editions:

Java 2 Micro Ed, Standard Ed, Enterprise Ed so imagine (SIP Micro Ed for
may be just basic residential telephony ? etc )

 

We need to also remember that SIP is inherently not for just "Telephony"
- although that is where the most push is.

So may be another idea would be to divide SIP spec into sections that
handle various commuication mediums, or various device types

SIP for Telephony, SIP for Video, SIP for Broadcast, SIP for ...

 

Just adding my 2 cents.

 

Syed Ahmad 
========================
Senior Engineer, Sales & Marketing Department 
Panasonic Communications Co (UK) Ltd 
Pencarn Way, Duffryn, Newport, South Wales, NP10 8YE,UK
Email:syed.ahmad AT eu.panasonic.com (replace AT with @)
Web: http://pccuk.panasonic.co.uk/ <http://pccuk.panasonic.co.uk/> 
Tel: +44 (0) 1633 653600 (Ext. 131) 
Fax: +44 (0) 1633 810041 
=========================== 

 

 

________________________________

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Peter Musgrave
Sent: 23 April 2007 13:48
To: techwg at sipforum.org
Subject: [SIPForum-techwg] (Interop) SHOULD in RFCs...

Hi, 

 

As part of trying to define specific interop requirements for use-case I
decided to start with looking at the SHOULD clauses in the RFCs from
Section (6). Past experience at SIPITs suggest to me that these clauses
cause a number of interop issues, in part because a number of parties
interpret a SHOULD as MAY....

 

To remind myself SHOULD means...

   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

 

So how many SHOULDs are there?

RFC2246 - 0

RFC2283 - 6

RFC2782 - 8

RFC3261 - 276

RFC3262 - 9

RFC3263 - 16

RFC3264 - 27

RFC3311 - 8

RFC3323 - 23

RFC3324 - 0

RFC3325 - 2

RFC3489 - 26

RFC3581 - 5

RFC3725 - 19

RFC4028 - 18

 

So the winner by far is RFC3261 (which is also the longest spec). 

 

This represents a fairly large degree of freedom in establishing
interop. 

 

Should we be more specific in listing the requirements for interop? If
we *really* want guaranteed interop then every SHOULD which will impact
interop will need to be resolved. 

 

Do we have the collective appetite for this?

 

Peter

 

 

 



Note:
Email domain @kmeuk.co.uk will change to @eu.panasonic.com.
ie: john.brown at kmeuk.co.uk changes to john.brown at eu.panasonic.com.
Please update your contact details now.


........................................................................
......
Confidentiality Notice
The information contained in this Email, and any attachments, is
intended for the named recipients only. It may contain confidential
and/or legally privileged information. If you are not the intended
recipient, you must not copy, store, distribute or take any action in
reliance on it. Any views expressed do not necessarily reflect the views
of the company.

If you receive this Email by mistake, please advise the sender by using
the reply facility in your Email software and then delete it.
........................................................................
.....

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20070423/dbae874f/attachment-0001.html