[SIPForum-techwg] Request for Comments - PreliminaryFeatureSetDocument

Fri May 18 10:52:59 EDT 2007

Thanks ...

Having missed the first call I had been wondering about the relationship with BLISS since I
have the same question there regarding TIA standards as I do with this group. So I'm happy
to see there is already a strategy as to how the Forum relates to work being done in BLISS.

Joanne
  ----- Original Message ----- 
  From: peter_blatherwick at mitel.com 
  To: Jay Batson 
  Cc: SIP Forum Tech WG 
  Sent: Friday, May 18, 2007 7:40 AM
  Subject: Re: [SIPForum-techwg] Request for Comments - PreliminaryFeatureSetDocument

  Hi again Jay, 

  I certainly share your concern for not getting tangled up in same work as BLISS mandate in IETF (or with others for that matter, notably TIA TR41.4 on 811-A).   

  My understanding (which may be flawed, or become flawed over time), is BLISS will actually look at "buckets" of features, and will recommend sets of methods that work (and, importantly, don't work) to make them interop correctly.   They would not spec individual features, or recommend single ways of initiating them.  Ie, for example "for the group of features related to shared line appearance, here is a collection of RFCs that play well together, and these ones do not".   

  While I agree there is potential overlap, which we must be very mindful of, I believe there is high value for SIP Forum to a) identify specific recommended feature sets at various levels (allow customer to understand what they are getting, in operational terms), and b) recommend *one* way to do them as the feature initiator.   

  I 1000% agree on the receiving side, it should be capabilities-based.  That's absolutely key to enabling innovation on new functionality.   

  This has been discussed on the conf calls a few times now, and I *think* there was rough consensus to at least flesh it out and see how it works.  (Give us something more concrete to flame at ;-)   So, suggest we go ahead and do that.   I am on the hook to at least generate a first stab at feature sets for Telephony.  (Still hoping for sometime this week, but admit that hope is now fading...  Will get that out soon as I can.)   

  -- Peter 

       Jay Batson <jay.batson at sipforum.org> 
        17.05.07 23:44 

                To:        peter_blatherwick at mitel.com 
                cc:        John Elwell <john.elwell at siemens.com>, SIP Forum Tech WG <techwg at sipforum.org>, Marek Dutkiewicz <marek.dutkiewicz at polycom.com> 
                Subject:        Re: [SIPForum-techwg] Request for Comments - Preliminary FeatureSetDocument 

  I ack and agree on capabilities (only, vs. features), since BLISS is supposed to be looking at features, and we're not trying to replace them; but to wrap them. 

  And I'm afraid I haven't read the docs that have come out of this, but be sure to think about whether this Recommendation should be looking "Up" any layers, e.g. hardware, codecs, etc. 

  On May 17, 2007, at 8:29 PM, peter_blatherwick at mitel.com wrote: 

  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

  _______________________________________________ 
  techwg mailing list 
  Send mail to: techwg at sipforum.org 
  Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg 

  ----------------- 
  Jay Batson 
  batsonjay at mac.com 
  +1-978-824-0111 (w) 
  +1-978-758-1599 (m) 

------------------------------------------------------------------------------

  _______________________________________________
  techwg mailing list
  Send mail to: techwg at sipforum.org
  Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20070518/1803cb20/attachment-0001.html 