[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:dean.willis at softarmor.com]
> 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:christer.holmberg at ericsson.com]
> >> 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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
> >>> sip-implementors at cs.columbia.edu for questions on current sip Use
> >>> sipping at ietf.org 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
> >> sip-implementors at cs.columbia.edu for questions on current sip Use
> >> sipping at ietf.org 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
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip