[SIPForum-discussion] [SIPForum-techwg] Request for Comments - Preliminary FeatureSetDocument

[peter_blatherwick at mitel.com]

Hi again John,

Agree on focusing on capabilities on the receiving end.  On the feature 
initiating end (eg the endpoint that wants to initiate, say, transfer just 
to pick on one), then I think we really do need to spell out how to do the 
particular feature, as the initiator. 

Peter
 




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


Peter,
 
Yes, I think we are saying more or less the same thing here. But the 
emphasis should be on capabilities rather than features, in the sense that 
if a device has the ability to respond to a certain set of capabilities, 
then this opens up a broad range of features that other devices can use 
without the need for standardisation. We just need to make sure we mandate 
sufficient capabilities to cover a reasonable set of popular features. In 
addition, where there is more than one way of initiating a feature, we 
need to recommend a way or ways that is/are compatible with those 
capabilities we make mandatory to respond to.
 
John

From: peter_blatherwick at mitel.com [mailto:peter_blatherwick at mitel.com] 
Sent: 17 May 2007 18:09
To: Elwell, John
Cc: discussion at sipforum.org; larry schessel; Dutkiewicz, Marek; 
techwg at sipforum.org; techwg-bounces at sipforum.org; Wesley. Hacker
Subject: RE: [SIPForum-techwg] Request for Comments - Preliminary 
FeatureSetDocument


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/9a31237a/attachment-0002.html>