Re: [Sip] INFO *is* Harmful; The Alternatives *are* Worse

[Henning Schulzrinne <hgs@cs.columbia.edu>]

I don't see the major problem of defining new methods. There seem to be 
two issues: programming and naming.

I believe that modern stacks, like those based on the JAIN SIP API, have 
no problems dealing with new methods. (Somebody who has more day-to-day 
experience with this should confirm this...)

Stack writers (for UA stacks) need to get used to the idea that new 
methods come along, so they should make it easy to register support for 
new (non-INVITE) methods. After all, this is pretty much just a table 
lookup.

In terms of naming, there are at least two sensible approaches:

- If you believe that the method may at some point be more generally 
applicable, give it a regular-looking SIP method name. If it doesn't get 
standardized but is deployed on a proprietary basis, your only 'problem' 
is that you may need to monitor the WGs to protest should somebody pick 
that name for something different. I suspect nobody wants to cause 
completely unnecessary interop problems, given that there is no scarcity 
of names. (We could have solved this problem differently and less 
informally, with the aid of IANA, but I've said my piece on that.)

The best solution is clearly to not deploy stuff until there is some 
generally-agreed upon sense that this is stable. (Presumably, this means 
that it's past the IESG, at least.) Since that can take a few years, 
unless your affiliation reads 3GPP, this is asking a bit, but that's a 
different discussion...

- If you believe that this is strictly your own proprietary thing that 
you don't want to bother documenting for whatever reason, make up your 
own name, such as "SNOWSHORE-EXPLODE-TERMINAL". Again, I wish there was 
a better mechanism for this, but that's a different discussion. 
Obviously, interoperability isn't going to be in the cards, but at least 
it is very obvious and obvious immediately that this is a non-standard 
extension, with a very well-understood error message (501) and 
negotiation mechanism (Allow). (No need to peek deep inside some generic 
INFO message and try to figure out what error indication would fit and 
no need to invent another Allow-* mechanism.)

I'm not advocating the second approach; the INFO abuse seems to 
indicate, however, that the current approach leaves implementors short.

(I don't think the approach in 
draft-narten-iana-experimental-allocations-03.txt is particularly 
applicable here since it assumes scarcity and advocates re-use of a 
small number range, which we don't need or want. We really don't want to 
designate INFO1, INFO2, INFO3, ..., INFO63 here...)

Henning


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip