Re: INFO Framework: Tags

On Nov 21, 2008, at 7:57 AM, Paul Kyzivat wrote:

>
>
> Dean Willis wrote:
>
>>> I don't in general
>>> see a need to specify this as part of the extension in general,  
>>> but if a
>>> particular package needs a feature tag, let it define one. Keep the
>>> extension simple.
>> Only standards-track RFCs can define SIP option tags under RFC  
>> 3427, and we have no plans to relax this requirement.
>> But we have a much looser policy for INFO packages; most will not  
>> be standards-track.
>> So, for those sorts of packages, an info-package option tag is  
>> potentially quite useful.
>
> For that to be useful, each package would need its own option.

Not exactly. If I know you don't support info-packages at all, I can  
readily presume you don't support any specific info-package, including  
those non-STD-track packages that can't possibly have their own SIP  
options tag.

Having discovered via OPTIONS that you support info-packages, I could  
then decide to offer the specific package needed in an INVITE. This  
can weed out a lot of abortive calls.

Without the info-package tag, I can't use OPTIONS to decide whether or  
not you support info-packages, and must probe with a real-live INVITE  
(which could make things a bit strange with lots of ring-answer-hangup  
calls).

Sure, if every UA supports info-package as a concept this isn't  
useful. But in a transitional phase (which is what we have) where a  
great many UAs are not supporting it al all, it's better than a call- 
and-hangup probe.


> While I guess we could define things such that each info-package  
> registration implied a corresponding option tag registration, then  
> that would be an end-around of the standards-track requirement for  
> defining option tags. We really don't want that, or we will have  
> people defining info-packages they don't intend to use, just to get  
> an option tag.
>

I agree heartily.

--
Dean


_______________________________________________
Sip mailing list  https://www.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