Subject: [Sip] Notes on Idraft-burger-sip-info-00

From: Spencer Dawkins <[email-masked]>
Date: Tue, 24 Jul 2007 09:58:34 -0500

I finally got to look at draft-burger-sip-info-00. I like what I see. I did
notice some nits, and am willing to provide a more formal review, but I 
support adoption of this draft as a WG deliverable, even in its current 
form.

You may have noticed that the MEDIACTRL WG editors were forced to discuss 
INFO in their specifications, because we currently have one draft providing 
guidance on INFO that people seem to generally agree with, but it expired 
years ago. I

Thanks, Eric, for taking this on.

Spencer

detailed comments...

     Intended status: Standards Track

Could/should this be a BCP? Informational isn't strong enough, but...

2.  Flaws With INFO

I'm remembering one other painful point - that INFO didn't provide a way to 
specify content-disposition if there is more than one reasonable choice. Did 
I make this up?

   An interesting issue is every INFO request traverses the same proxy
   path as any other dialog-related SIP request.  Proxies in the path
   that have no interest in INFO requests still must process the
   request.  This may put undue load on those proxies.  What makes this
   issue interesting, and not necessarily a proxy, is one may wish the

Not sure what "and not necessarily a proxy" was supposed to actually be - 
edit error?

   request to traverse the proxy.  The problem is there is no way for
   proxies to not whether or not they have an interest in INFO requests.
   Getting the requests is an all-or-nothing proposition, driven by
   Record-Route.

3.  INFO Alternatives

   What if you think you need UA-to-UA application session signaling?

This sounds like an invitation to therapy :D. Perhaps "If your new 
application requires UA-to-UA session level signaling, what alternatives 
exist that provide this without using INFO?"

   There are four broad classes of session signaling available.  The
   choice depends on the circumstances.
   o  State updates
   o  User stimulus
   o  Direct signaling channel
   o  Proxy-aware signaling

3.1.  State Updates

   This is the broad class of one User Agent updating another with
   changes in state.  Clearly, state updates are the provenance of the
   SUBSCRIBE/NOTIFY [8] event framework.

Excellent vocabulary. Perhaps "Clearly the SUBSCRIBE/NOTIFY [8] event 
framework was specifically designed to meet this need" might be more 
accessible?

3.2.  User Stimulus: Touch Tones and Others

   This is the class of the user entering stimulus at one User Agent,
   and the User Agent transporting that stimulus to the other.  A key
   thing to realize is key presses on the telephone keypad is user
   stimulus.  Thus, the appropriate mechanism to use here is KPML [9].

3.3.  Direct Signaling Channel

   State updates and user stimulus tend to have relatively few messages
   per session.  Sometimes, User Agents have a need for exchanging a

s/have a need for exchanging/need to exchange/

   relatively high number of messages.  In addition, User Agents may
   have a need for a relatively low-latency exchange of messages.  In
   this latter case, the User Agent may not be able to tolerate the
   latency introduced by intermediate proxies.  Likewise, the
   intermediate proxies may have no interest in processing all of that
   data.

... and it's not obvious how they would process it anyway, if the INFO 
payload is really only meaningful to UAs.

   In this case, establishing a separate, direct control channel, as in
   MSRP [10] or MRCPv2 [11] is appropriate.

3.4.  Proxy-Aware Signaling

   Sometimes, one does want proxies to be in the signaling path for UA-
   to-UA application signaling.  In this case, the use of a SIP request
   is appropriate.  To date, there are no mechanisms for completely
   disambiguating INFO requests.  For example, one could create a
   registry of INFO packages.  The definition of the package would
   define the contexts for the various MIME Content-Types, as well as
   the context of the request itself.  However, a package can have
   multiple content types.  Moreover, having the context, or package
   identifier, at the SIP level precludes bundling multiple contexts
   responding in the same INFO request.  For example, a User Agent might
   want to bundle two different responses in a multipart/mixed MIME body
   type.

   Because there is no difference in either the protocol machinery or
   registration process due to these factors, we will not create an INFO
   framework.  If one needs a SIP User Agent-to-SIP User Agent
   application session signaling transport protocol that touches all
   Record-Route proxies in a path, one MUST create a new SIP method as
   described in Section 27.4 of RFC 3261 [2].

4.  INFO Use Clarification

   There is no way to unambiguously use the INFO request in a general
   framework.  The IETF has already standardized use of INFO for SIP-T
   [4].  Thus we will not deprecate the use of INFO for that purpose.
   However, this document explicitly updates INFO [3], in that one MUST
   NOT use the INFO request for anything other than the use described by
   SIP-T.

I'm confused here. Is it "one MUST NOT use INFO" or that "new applications 
MUST NOT define new uses for INFO"?

   In recognition of existing, proprietary use of INFO, proxies MUST NOT
   take any action other than that described by RFC 3261 and RFC 2976
   with respect to handling INFO requests.

      OPEN ISSUE: Do we bow to reality, and say, "INFO is the Port 80 of
      the 2000's.  SBC's will never keep up with newly minted SIP method
      requests, so we keep INFO so we can have a poliferation of
      protocols tunneled over SIP?"

Well, I think your point is actually that SIP is the Port 80 of the 2000s, 
and INFO is the port 80 of SIP signaling, so the situation is even more 
frustrating than your text suggests. My preference is to remove this OPEN 
ISSUE text and publish the draft so we will all drop INFO as a choice for 
future applications.

Appendix A.  Acknowledgements

   Standing on the shoulders of giants.  Jonathan Rosenberg did the
   original "INFO Considered Harmful" on 26 December 2002, which
   influenced the work group and this document.  Likewise, Dean Willis
   influenced the text from his "Packaging and Negotiation of INFO
   Methods for the Session Initiation Protocol" of 15 January 2003.  My,
   we have been working on this for a long time!

Could you mention that these were both Internet-Drafts (ex. "in an 
Internet-Draft submitted on 26 December 2002")? 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 24 Jul 2007 11:23:24 -0500

I spoke at the mike a minute ago about having this draft done in SIP, and 
then Rohan suggested that BLISS would be the right place to do the work. I 
would be OK with that, too, if others see it the same way.

Dean called the question as "do something IN THIS WG", which is fair 
(because that's the WG he chairs), but I would support "doing something IN 
THE RIGHT WG", if the chairs and ADs think there's a better home for the 
work.

Pointing to a MEDIACTRL draft is not the right thing to do, and pointing to 
a long-expired draft that people may or may not have agreed with at the time 
is even worse.

Spencer

> INFO in their specifications, because we currently have one draft 
> providing guidance on INFO that people seem to generally agree with, but 
> it expired years ago. I
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jul 2007 12:38:25 -0400

I was thinking the same thing. Dealing with this in the context of 
"features" that use it has some promise of at least demonstrating the 
problems with existing approaches to those that matter.

	Paul

Spencer Dawkins wrote:
> I spoke at the mike a minute ago about having this draft done in SIP, 
> and then Rohan suggested that BLISS would be the right place to do the 
> work. I would be OK with that, too, if others see it the same way.
> 
> (because that's the WG he chairs), but I would support "doing something 
> IN THE RIGHT WG", if the chairs and ADs think there's a better home for 
> the work.
> 
> Pointing to a MEDIACTRL draft is not the right thing to do, and pointing 
> to a long-expired draft that people may or may not have agreed with at 
> the time is even worse.
> 
> Spencer
> 
> 
>> notice some nits, and am willing to provide a more formal review, but 
>> I support adoption of this draft as a WG deliverable, even in its 
>> current form.
>>
>> You may have noticed that the MEDIACTRL WG editors were forced to 
>> discuss INFO in their specifications, because we currently have one 
>> draft providing guidance on INFO that people seem to generally agree 
>> with, but it expired years ago. I
>>