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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
