Subject: [RAI] Option-tag Expert guidance

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Apr 2010 17:57:09 -0400

Starting strawman for option-tag review Expert guidance:

1) The Expert Reviewer will generally consult the IETF DISPATCH working group mailing list or its designated successor.

2) Unless exempted by the RAI Area Directors, the Expert Reviewer will reject the request if any of the following:
	a) The language of the document does not explicitly forbid putting the option-tag in the Require and/or Proxy-Require header fields.
	b) The extension is implicitly required to be supported by UAS' or intermediate nodes, in order for the Request its option-tag is in to function properly.  In other words, if the extension would change the behavior of the Request such that it would have been more appropriate to use the option-tag in a Require or Proxy-Require header field.
	c) The document does not specify sufficient detail for interoperability as a stand-alone document.  It may reference other IETF Standards-track RFCs, for example, but not private or proprietary documents.
	d) The document does not provide example message flows.
	e) The extension relies on a URI, and the document does not specify all URI schemes it applies to (e.g., sips, tel).
	f) The extension changes the SIP Offer/Answer model in any way.
	g) The extension relies on local policies for intermediate SIP nodes, such that it requires all intermediate nodes to have the same local policies in an inter-domain model.
	h) The option-tag is used in requests which could cross through multiple SIP domains, whereby the extension's behavior could become inconsistent.  For example, due to being forwarded to/through a third domain, or through a B2BUA which does not know about the option-tag.

[maybe]
	i) The document does not separate the use of the mechanism in a particular request, from the option-tag.  It needs to be clear that the option-tag indicates system-level "support" for a mechanism, not that the extension is currently being used for the particular SIP Request which the option-tag is in.  For example, an OPTIONS request's response indicates Supported extensions identified by option-tags, but does not mean the OPTION response itself is *using* the mechanism.  Typically, a SIP header is used for indicating the mechanism is in use, and the option-tag indicates support for the header.
[/maybe]

3) The Expert Reviewer may use reasonable discretion with regard to the above criteria, with the understanding that the goal of registering SIP option-tags is to enhance interoperability of extensions between different implementations, but without breaking the ability for devices which support the extension to function with devices that do not, and vice-versa.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 12:19:51 +0200

Hi,

Now allowing it in (Proxy-)Require is ok.

But, what about using it with the sip.extensions feature tag? I think that should be allowed, in order to request proxies to fork towards UASs that support the feature.

However, section 5 of RFC3840 says:

"When using the "sip.extensions" feature tag, a UA MUST NOT include values that
correspond to option tags not standardized in IETF standards track RFCs."

...which means that non-standards track option tags are not allowed.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 15. huhtikuuta 2010 0:57
> To: [email-masked]
> Subject: [RAI] Option-tag Expert guidance
> 
> 1) The Expert Reviewer will generally consult the IETF 
> DISPATCH working group mailing list or its designated successor.
> 
> 2) Unless exempted by the RAI Area Directors, the Expert 
> Reviewer will reject the request if any of the following:
> 	a) The language of the document does not explicitly 
> forbid putting the option-tag in the Require and/or 
> Proxy-Require header fields.
> 	b) The extension is implicitly required to be supported 
> by UAS' or intermediate nodes, in order for the Request its 
> option-tag is in to function properly.  In other words, if 
> the extension would change the behavior of the Request such 
> that it would have been more appropriate to use the 
> option-tag in a Require or Proxy-Require header field.
> 	c) The document does not specify sufficient detail for 
> interoperability as a stand-alone document.  It may reference 
> other IETF Standards-track RFCs, for example, but not private 
> or proprietary documents.
> 	e) The extension relies on a URI, and the document does 
> not specify all URI schemes it applies to (e.g., sips, tel).
> 	g) The extension relies on local policies for 
> intermediate SIP nodes, such that it requires all 
> intermediate nodes to have the same local policies in an 
> inter-domain model.
> 	h) The option-tag is used in requests which could cross 
> through multiple SIP domains, whereby the extension's 
> behavior could become inconsistent.  For example, due to 
> being forwarded to/through a third domain, or through a B2BUA 
> which does not know about the option-tag.
> 
> [maybe]
> 	i) The document does not separate the use of the 
> mechanism in a particular request, from the option-tag.  It 
> needs to be clear that the option-tag indicates system-level 
> "support" for a mechanism, not that the extension is 
> currently being used for the particular SIP Request which the 
> option-tag is in.  For example, an OPTIONS request's response 
> indicates Supported extensions identified by option-tags, but 
> does not mean the OPTION response itself is *using* the 
> mechanism.  Typically, a SIP header is used for indicating 
> the mechanism is in use, and the option-tag indicates support 
> for the header.
> [/maybe]
> 
> 3) The Expert Reviewer may use reasonable discretion with 
> regard to the above criteria, with the understanding that the 
> goal of registering SIP option-tags is to enhance 
> interoperability of extensions between different 
> implementations, but without breaking the ability for devices 
> which support the extension to function with devices that do 
> not, and vice-versa.  
> 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 12:27:06 +0200

Not allowing it in (Proxy-)Require is ok, that is.

> Behalf Of Christer Holmberg
> Sent: 15. huhtikuuta 2010 13:20
> To: Hadriel Kaplan; [email-masked]
> Subject: Re: [RAI] Option-tag Expert guidance
> 
> 
> Hi,
> 
> But, what about using it with the sip.extensions feature tag? 
> I think that should be allowed, in order to request proxies 
> to fork towards UASs that support the feature.
> 
> "When using the "sip.extensions" feature tag, a UA MUST NOT 
> include values that correspond to option tags not 
> standardized in IETF standards track RFCs."
> 
> Behalf Of 
> > Hadriel Kaplan
> > 1) The Expert Reviewer will generally consult the IETF DISPATCH 
> > working group mailing list or its designated successor.
> > 
> Reviewer will 
> > reject the request if any of the following:
> forbid putting 
> > the option-tag in the Require and/or Proxy-Require header fields.
> by UAS' or 
> > intermediate nodes, in order for the Request its option-tag 
> is in to 
> > function properly.  In other words, if the extension would 
> change the 
> > behavior of the Request such that it would have been more 
> appropriate 
> > to use the option-tag in a Require or Proxy-Require header field.
> > interoperability as a stand-alone document.  It may reference other 
> > IETF Standards-track RFCs, for example, but not private or 
> proprietary 
> > documents.
> not specify 
> > all URI schemes it applies to (e.g., sips, tel).
> intermediate SIP nodes, 
> > such that it requires all intermediate nodes to have the same local 
> > policies in an inter-domain model.
> > 	h) The option-tag is used in requests which could cross through 
> > multiple SIP domains, whereby the extension's behavior could become 
> > inconsistent.  For example, due to being forwarded 
> to/through a third 
> > domain, or through a B2BUA which does not know about the option-tag.
> > 
> > [maybe]
> > 	i) The document does not separate the use of the mechanism in a 
> > particular request, from the option-tag.  It needs to be clear that 
> > the option-tag indicates system-level "support" for a 
> mechanism, not 
> > that the extension is currently being used for the particular SIP 
> > Request which the option-tag is in.  For example, an 
> OPTIONS request's 
> > response indicates Supported extensions identified by 
> option-tags, but 
> > does not mean the OPTION response itself is *using* the mechanism.  
> > Typically, a SIP header is used for indicating the mechanism is in 
> > use, and the option-tag indicates support for the header.
> > [/maybe]
> > 
> > 3) The Expert Reviewer may use reasonable discretion with regard to 
> > the above criteria, with the understanding that the goal of 
> > registering SIP option-tags is to enhance interoperability of 
> > extensions between different implementations, but without 
> breaking the 
> > ability for devices which support the extension to function with 
> > devices that do not, and vice-versa.
> >

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 16 Apr 2010 13:19:06 -0400

> Starting strawman for option-tag review Expert guidance:

I'd prefer Specification Required, which implies Expert Review but adds
the requirement that the specification be "documented in a permanent and
readily available public specification, in sufficient detail so that
interoperability between independent implementations is possible".

> 3) The Expert Reviewer may use reasonable discretion with regard to the above criteria, with the understanding that the goal of registering SIP option-tags is to enhance interoperability of extensi…

One possible addition would be to allow First Come First Served
additions to the registry of private option tag values, so long as the
value begins with a string whose value is a recognized trademark (or
equivalent name).  This would allow private vendors to provide the
registry with pointers to the values they use, with at least the contact
information and possibly specifications.  This would allow things like
'examplecorp-foobar' options.

I still don't like the blanket prohibition against use in Requires or
Proxy-Requires... but I appear to be banging my head against a wall on
that one, and implementors will do it anyway, so whatever...