[SIPForum-techwg] Request for Comments - Preliminary FeatureSetDocument
peter_blatherwick at mitel.com
peter_blatherwick at mitel.com
Mon May 21 18:05:38 EDT 2007
Hi Richard,
> BLISS is a BOF and not a Working Group
Fair enough. It did get approved to become a WG at last IETF conf though.
But I have not seen an official charter get posted yet. There is still
a bit of charter-chatter going on I believe.
-- Peter
"Richard Shockey" <richard at shockey.us>
18.05.07 17:49
To: <peter_blatherwick at mitel.com>, "'Jay Batson'"
<jay.batson at sipforum.org>
cc: "'SIP Forum Tech WG'" <techwg at sipforum.org>
Subject: RE: [SIPForum-techwg] Request for Comments -
Preliminary FeatureSetDocument
Remember BLISS is a BOF and not a Working Group… It’s a theory …
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of peter_blatherwick at mitel.com
Sent: Friday, May 18, 2007 10:40 AM
To: Jay Batson
Cc: SIP Forum Tech WG
Subject: Re: [SIPForum-techwg] Request for Comments - Preliminary
FeatureSetDocument
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20070521/f96c247c/attachment-0001.html
More information about the techwg
mailing list