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
