Re: INFO Framework: Tags

You seem to be arguing that packages themselves may need to have option
tags, rather than the extension itself, which does not answer the
question I asked. 

What I asked was whether there was a need to have an option tag
specifically for the info-package extension.

There were no option tags for pre package info behaviour, so there is no
information to tell you that if I don't support the new extension that I
supported the previous incarnation of INFO. So I do not see how that can
be used for fallback.

regards

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[email protected]] 
> Sent: Thursday, November 20, 2008 6:24 PM
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; Elwell, John; Eric Burger; SIP List
> Subject: Re: [Sip] INFO Framework: Tags
> 
> 
> The option tag is used in OPTIONS responses (and in Supported 
> header fields in other responses) to inform a correspondent 
> that the node in question supports this extension, 
> potentially leading to a decision as to which behavior to 
> apply to future requests.
> 
> It is also used in Require header fields of requests to cause 
> the request to be rejected by any UAS that does not 
> understand the extension.  This is potentially critical for 
> applications that find themselves completely dependent on the 
> extension.
> 
> One might ask whether this is critical; after all the INVITE 
> exchange will tell us what info packages (if any) the far end 
> is willing to use. What is the difference between not using 
> INFO packages and not supporting them?
> 
> The answer is in the fallback to pre-package INFO behavior. A 
> node supporting INFO packages will, IIRC (or at least "if I 
> get my way") , always use packages when sending INFO. A node 
> not supporting INFO packages is likely to send old-style 
> un-negotiated INFO, meaning you might need to be prepared 
> with that behavior. Being informed (by
> Supported) which state applies might be useful.
> 
> --
> Dean
> 
> 
> 
> On Nov 20, 2008, at 10:44 AM, DRAGE, Keith (Keith) wrote:
> 
> >> Option-tag:
> >> -----------
> >>
> >> I strongly think we should define an option tag for info packages.
> >
> > I think you need to provide more than this in terms of 
> explanation.  
> > What
> > interoperability issues do you think is solved by providing 
> an option 
> > tag for the extension itself, as opposed to individual packages?
> >
> > Give us some valid scenarios.
> >
> > regards
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: Christer Holmberg [mailto:[email protected]]
> >> Sent: Thursday, November 20, 2008 1:12 PM
> >> To: DRAGE, Keith (Keith); Elwell, John; Eric Burger; SIP List
> >> Subject: RE: [Sip] INFO Framework: Tags
> >>
> >>
> >> Hi,
> >>
> >> Feature-tags:
> >> -------------
> >>
> >>> I agree with John here.
> >>>
> >>> I would include an informative reference to RFC 3427 
> indicating that
> >> any draft that requires option tags for a package
> >>> would need to have the status required for option tag 
> registration.
> >>
> >> One option would have been to define an info feature tag which can 
> >> list package value, and each package could then specify a value.
> >>
> >> E.g sip.info="dtmf-packkage, isup-package"
> >>
> >> But, I am ok with John's proposal also, but I think we should add 
> >> some text as suggested by Keith.
> >>
> >>
> >> Option-tag:
> >> -----------
> >>
> >> I strongly think we should define an option tag for info packages.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: [email protected] [mailto:[email protected]] On
> >> Behalf Of
> >>> Elwell, John
> >>> Sent: Thursday, November 20, 2008 1:16 AM
> >>> To: Eric Burger; SIP List
> >>> Subject: Re: [Sip] INFO Framework: Tags
> >>>
> >>> Eric,
> >>>
> >>> If an individual package requires an option tag, that
> >> option tag could
> >>
> >>> be defined in the RFC that defines the package, which would
> >> need to be
> >>
> >>> standards track. I don't think we need to say anything about this.
> >>>
> >>> Similar situation for media tags, except that RFC would not
> >> need to be
> >>
> >>> standards track.
> >>>
> >>> John
> >>>
> >>>> -----Original Message-----
> >>>> From: [email protected] [mailto:[email protected]] On
> >>> Behalf Of
> >>>> Eric Burger
> >>>> Sent: 20 November 2008 00:48
> >>>> To: SIP List
> >>>> Subject: [Sip] INFO Framework: Tags
> >>>>
> >>>> Do we want to specify media tags to indicate package support?
> >>>>
> >>>> Do we want to specify SIP option tags to require Info
> >>> Package support?
> >>>>
> >>>> Comments welcome.
> >>>>
> >>> _______________________________________________
> >>> 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
> >>>
> >> _______________________________________________
> >> 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
> >>
> > _______________________________________________
> > 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
> >
> 
> 
_______________________________________________
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