[SIPForum-discussion] [SIPForum-techwg] Request for Comments - Preliminary Feature SetDocument

[peter_blatherwick at mitel.com]

Hi John, 
I agree with most all of what you are saying here.  I'll paraphrase a bit 
to test if we are actually on the same page. 

I believe the "must be able to receive" aspect is important for the 
reasons you state: improved interop for possibly unknown to the receiver 
operations initiated by another endpoint (or server in between).  This 
will tend to drive ability to respond to RFC <blah> into core protocol 
support, mandatory for all (and Refer is a great example of that). 

I believe this thinking is it is also in line with Rohan's suggestion (to 
which I believe we nominally agreed) on stating, roughly "for feature X, 
MUST be able to respond to all of methods A, B, C, and MUST initiate 
feature X with one of A, B, C (A is recommended)". 

Of course, I have not though through how to actually structure this in the 
document...   If we do follow this approach, we will wind up with the same 
RFCs listed many times in different sections, but I think that's actually 
ok as long as we can find a way to make it very brief and easy to follow. 

Cheers, 
Peter






"Elwell, John" <john.elwell at siemens.com>
17.05.07 02:09
 
        To:     peter_blatherwick at mitel.com, larry schessel 
<lschesse at gmail.com>
        cc:     "Dutkiewicz, Marek" <marek.dutkiewicz at polycom.com>, 
techwg at sipforum.org, discussion at sipforum.org, techwg-bounces at sipforum.org, 
"Wesley. Hacker" <wesley at broadsoft.com>
        Subject:        RE: [SIPForum-techwg] Request for Comments - 
Preliminary Feature     SetDocument


Peter,
 
You wrote:
 
"My main comment is the content is (so far) basically just a list of
RFCs, with no support for why that particular list needs to be
supported.  The sections are called "features" (in Markus' listing), but
do not really list what the features are, just the RFCs.  For example,
if REFER is required, why, what user operations does it support?  I
think, for each section, we need to outline specifically what features
are expected to be supported, may even need to roughly define the
features (*gasp*).   Then, what RFCs (perhaps even specific sections)
are needed to do so.  If there are multiple ways pointed by the RFCs,
then pick *one*. as the recommended."

I agree that it is important to state what parts of an RFC must be
implemented, e.g., it might be important to support receipt of
something, in order to provide adequate support for features used by
other endpoints, but less important to support sending something. The
SIP philosophy is to specify a tool set of capabilities that can then be
used to build a large number of features. Taking the REFER method as an
example, if endpoints support the REFER method, that can enable a number
of different features. More specifically, by supporting receipt of a
REFER request, you can operate in an environment where other endpoints
implement features that rely on the REFER method. The ability to support
receipt of a REFER request is an important capability, and we don't need
to enumerate the features that this might enable.

Of course, we might also conclude that it is important that a device be
able to initiate call transfer, in which case, in specifying this, we
would need to require the ability to send a REFER request. But I see
this as a less important requirement than the ability to receive a REFER
request.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070517/4162022f/attachment-0002.html>