Subject: [RAI] Time for a feature tag?

From: "Dean Willis" <[email-masked]>
Date: Wed, 14 Apr 2010 18:48:37 -0400

How about creating a new extension header field called Feature. This header 
field takes a list of feature values, and has the semantic that the message 
sender supports the named features. The feature namespace is entirely 
orthogonal to the option-tag namespace. No feature can change the basic 
state machine of SIP nor nullify a negotiated option. Further, nodes ising 
features MUST be able to fall back to basic SIP in the absence of mathching 
feature support in a correspondent node.

Isn't that what you REALLY want?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Apr 2010 19:24:32 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Wednesday, April 14, 2010 6:49 PM
> 

Basically, yes, except we still want it to be Expert Review I think.

And we've joked before that what we really need is a single IANA registered option-tag named "option-tags", to indicate support for a header named "Option-Tags" to carry supported option-tags of a different namespace not requiring a standards-track RFC.

But does defining a new header help avoid the underlying problem/concern/issues?

Or are you being facetious?

-hadriel

---

From: "Andrew Allen" <[email-masked]>
Date: Wed, 14 Apr 2010 18:30:56 -0500

Accept-Contact: *;feature=my-new-feature;require;explicit

I think you just got a non interoperable extension to SIP equivalent to
an option-tag in a Require header field.

So I think using feature tags for this isn't the preferred way to go (I
think this is more the sort of unfortunate hack that people are doing to
get around registering an option-tag).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Wednesday, April 14, 2010 7:25 PM
To: Dean Willis; [email-masked]
Subject: Re: [RAI] Time for a feature tag?

And we've joked before that what we really need is a single IANA
registered option-tag named "option-tags", to indicate support for a
header named "Option-Tags" to carry supported option-tags of a different
namespace not requiring a standards-track RFC.

But does defining a new header help avoid the underlying
problem/concern/issues?

-hadriel
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 14 Apr 2010 20:10:30 -0400

Ok could a "feature" carry metadata about the contact URI? You certainly
know where I'm going with this :-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Wednesday, April 14, 2010 6:49 PM
To: [email-masked]
Subject: [RAI] Time for a feature tag?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 10:09:08 +0200

Hi,

You can use option-tags an A-C also.

Accept-Contact: *;sip.extensions=my-option-tag;require;explicit

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 15. huhtikuuta 2010 2:31
To: Hadriel Kaplan; Dean Willis; [email-masked]
Subject: Re: [RAI] Time for a feature tag?

I think you just got a non interoperable extension to SIP equivalent to an option-tag in a Require header field.

So I think using feature tags for this isn't the preferred way to go (I think this is more the sort of unfortunate hack that people are doing to get around registering an option-tag).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Wednesday, April 14, 2010 7:25 PM
To: Dean Willis; [email-masked]
Subject: Re: [RAI] Time for a feature tag?

Dean
> How about creating a new extension header field called Feature. This 
> header field takes a list of feature values, and has the semantic that 
> the message sender supports the named features. The feature namespace 
> is entirely orthogonal to the option-tag namespace. No feature can 
> change the
basic
> features MUST be able to fall back to basic SIP in the absence of 
> mathching feature support in a correspondent node.
> 

-hadriel