Hi Keith, My proposal is that we define an option tag for the EXTENSION - like we do for most other extensions.
Whether we have a feature tag for the extension, or separate feature tags for each package, has nothing to do with the option tag. Regards, Christer -----Alkuperäinen viesti----- Lähettäjä: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] Lähetetty: to 20.11.2008 19:32 Vastaanottaja: Dean Willis Kopio: Christer Holmberg; Elwell, John; Eric Burger; SIP List Aihe: RE: [Sip] 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
