Subject: Re: [Sipping] I-D Action:draft-audet-sipping-feature-ref-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Sun, 17 Feb 2008 19:59:18 -0500

Interesting!

I'm struggling with one thing:

If the intent is not to define the precise behavior that should result 
from receipt of one of these requests, then how *are* the semantics of 
each such feature to be defined?

Up until now we have been trying to avoid the definition of features 
precisely because we didn't want to be in the business of standardizing 
features. This draft is clearly going in a different direction.

	Paul
_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Feb 2008 12:02:56 -0600

I think this may be a "cultural difference".

In the Enterprise (contrary to Carrier space), "features" were never standardized 
(at least, not in practice). Every vendor has its own version of "features" and they
are quite different from one vendor to another. 

You need to think of these "features" as primitives.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Sunday, February 17, 2008 16:59
> To: sipping
> Subject: Re: [Sipping] I-D 
> Action:draft-audet-sipping-feature-ref-00.txt
> 
> 
> Interesting!
> 
> If the intent is not to define the precise behavior that 
> should result from receipt of one of these requests, then how 
> *are* the semantics of each such feature to be defined?
> 
> Up until now we have been trying to avoid the definition of 
> features precisely because we didn't want to be in the 
> business of standardizing features. This draft is clearly 
> going in a different direction.
> 
> 	Paul
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Alan Johnston <[email-masked]>
Date: Mon, 18 Feb 2008 12:19:12 -0600

Paul,

I agree that these features we are invoking must be well understood by 
both parties - a couple of sentences for each should be enough to 
explain what should happen, and this should not specify exactly how it 
should happen.

If the feature is so complicated that detailed descriptions and call 
flows are needed, then I'd suggest it is not a good candidate for 
standardization, as resulting interop is likely to be low.

This approach will not solve every problem, but it will solve the 80% 
which are of most interest and will enable many, many useful SIP 
applications.

Hope this helps.

Thanks,
Alan

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 13:37:38 -0500

Alan,

I guess you are trying to thread almost the same needle as BLISS. As 
with that, it seems to be worth trying.

So I guess you would be putting the few sentences into the registration 
of the URN. Somebody will need to do that. Perhaps that is a task for 
BLISS. The proof will be in whether there becomes an ongoing need to 
keep clarifying the definitions.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 26 Feb 2008 20:55:57 +0000

Francois,

I think this is a useful draft. Just a few comments.

"CSTA works fine for
   legacy PBXs with legacy phones but is problematic in a SIP
   environment.  For example, SIP includes totally new capabilities such
   as presence and instant messaging.  SIP also supports multiple users
   with multiple devices operating at once, and with complex User
   Interfaces.  Furthermore, multiple applications may want to
   simultaneously wish to interact with the device.  Because of the lack
   of a native mechanism mechanism to achieve such control for SIP,
   implementors have had to implement such techniques as mapping CSTA's
   ASN.1 encoding to XML then encapsulate it into SIP INFO requests in
   order to tunnel it to a SIP B2BUA [ECMA323], which then maps it to
   proprietary device control protocols or to SIP with proprietary and
   incompatible extensions."
I would not say that CSTA is problematic in a SIP environment. CSTA
provides some support for presence and IM, for multiple users with
multiple devices, and there is nothing to prevent multiple applications
simultaneously interacting with a device using CSTA. CSTA "primitives"
are mapped directly to XML syntax - not via ASN.1. CSTA over SIP is not
forced to go via a B2BUA any more than REFER requests in your draft
might go via a B2BUA. I don't think that proprietary extensions to SIP
are necessary to carry CSTA. One might criticise CSTA's use of INFO for
encapsulation in SIP, but otherwise I think it is mostly standard SIP.
Therefore, although I can see that the mechanism proposed in your draft
is an elegant solution, I would not build the justification on perceived
shortcomings of CSTA.

"When the
   norefersub option tag is present, a REFER request which would have
   created a new subscription and dialog becomes a standalone
   transaction instead, eliminating a multiple dialog usage."
This doesn't quite follow. Even without norefersub, sending the REFER
outside the context of an existing dialog would not lead to multiple
dialog usage - it would instead lead to an additional dialog. I agree
that use of norefersub is beneficial, but not for the reason you state.
Interestingly, one could send a REFER request with norefersub within the
context of an existing dialog (assuming the UAS has already indicated
support for norefersub) and this too would avoid multiple usages of the
dialog. I am not advocating this - just remarking on this property.

"In the most common usage, the controller maintains a long duration
   subscription to the dialog package, and sends REFER requests in
   seperate dialogs Each REFER would include the norefersub option-tag
   in a Supported header field."
I would contend that it sends the REFER request outside any dialog.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 17 February 2008 22:30
> To: [email-masked]
> Subject: I-D Action:draft-audet-sipping-feature-ref-00.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : Feature Referral in the Session 
> Initiation Protocol (SIP)
> 	Author(s)       : F. Audet, et al.
> 	Filename        : draft-audet-sipping-feature-ref-00.txt
> 	Pages           : 20
> 	Date            : 2008-02-17
> 
> Feature referral allows for an application to make a high level
> request to a User Agent to perform an action or "feature", and let
> the the User Agent actually execute the feature as it sees fit.
> Feature referral uses the SIP REFER method with a Refer-To header
> field containing a URN.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-audet-sipping-featur
> e-ref-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in 
> the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-audet-sipping-feature-ref-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-audet-sipping-feature-ref-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 28 Feb 2008 22:23:45 -0600

Thanks John. Good comments, I'll look into it. 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Tuesday, February 26, 2008 12:56
> To: Audet, Francois (SC100:3055); [email-masked]
> Subject: RE: I-D Action:draft-audet-sipping-feature-ref-00.txt
> 
> Francois,
> 
> I would not say that CSTA is problematic in a SIP 
> environment. CSTA provides some support for presence and IM, 
> for multiple users with multiple devices, and there is 
> nothing to prevent multiple applications simultaneously 
> interacting with a device using CSTA. CSTA "primitives"
> are mapped directly to XML syntax - not via ASN.1. CSTA over 
> SIP is not forced to go via a B2BUA any more than REFER 
> requests in your draft might go via a B2BUA. I don't think 
> that proprietary extensions to SIP are necessary to carry 
> CSTA. One might criticise CSTA's use of INFO for 
> Therefore, although I can see that the mechanism proposed in 
> your draft is an elegant solution, I would not build the 
> justification on perceived shortcomings of CSTA.
> 
> "When the
> This doesn't quite follow. Even without norefersub, sending 
> the REFER outside the context of an existing dialog would not 
> lead to multiple dialog usage - it would instead lead to an 
> additional dialog. I agree that use of norefersub is 
> beneficial, but not for the reason you state.
> Interestingly, one could send a REFER request with norefersub 
> within the context of an existing dialog (assuming the UAS 
> has already indicated support for norefersub) and this too 
> would avoid multiple usages of the dialog. I am not 
> advocating this - just remarking on this property.
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > request to a User Agent to perform an action or "feature", 
> and let the 
> > the User Agent actually execute the feature as it sees fit.
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping

---

From: [email-masked]
Date: Fri, 29 Feb 2008 22:31:27 -0500

I'd prefer to see a new method defined for this functionality.  REFER
is woefully overloaded already, and feature-ref would add yet another
set of Do What I Mean hueristics to any REFER implementation.

Dale