Subject: Re: [Sip] Comments on Last Call of "Extending Reason-header for Preemption Ev...

From: [email-masked]
Date: Thu, 2 Jun 2005 09:46:57 EDT

In a message dated 5/29/2005 6:17:03 PM Eastern Daylight Time, 
[email-masked] writes:

> >Section 7 IANA Considerations
> >As noted above, this section contains an erroneous statement about what 
> >"syntax shall be used". At the same time, it is unclear what the IANA 
> >registration requirements are. For example, this part implies that IANA 
> >needs to register the text strings, when there is clearly no need for that.
> 

You didn't respond to the above comment I submitted. I suspect it requires a 
little better explanation on my part.

Since this draft defines a new reason value, it must be assumed that it is 
based on, and follows everything in, RFC 3326. However, it doesn't make a clear 
statement that the syntax follows what is defined in RFC 3326.

As I read the syntax in Section 2 of RFC 3326, the reason header may contain 
multiple reason-values (e.g., both SIP and Q.850) and for each protocol may 
specify multiple reason-parameters (e.g., cause value and text), and each is 
optional. The syntax defined in Section 2 allows the use of a cause value without 
the accompanying text string, although the examples don't ever show that.

(However, the final paragraph of Section 2 of RFC 3326 implies that multiple 
protocols are indicated by the use on multiple headers - "multiple Reason 
lines" - not by putting multiple protocols into one header.)

This draft, on the other hand, contains statements like:

the following syntax shall be used:

         Reason: preemption ;cause=1 ;text="UA Preemption"

This implies that the text part is mandatory.

It seems that part of the problem is the way that the syntax was defined in 
RFC 3326. While it implied that the text part is always used, the formal 
definition shows it as optional.

Concerning IANA registration, RFC 3326 only required the registration of the 
protocols (SIP and Q.950) since all cause values and text strings were defined 
elsewhere. This draft extends that model by requiring the registration of 
more than the new protocol ("preemption"). It implies that both cause values and 
text strings need to be registered, but this is not clear. Rather than 
containing more description of the procedures for use of these parameters, Section 7 
needs explicit statements about IANA registration requirements.

Mike Pierce

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Jun 2005 17:09:36 -0500

At 09:46 AM 6/2/2005 -0400, [email-masked] wrote:
>You didn't respond to the above comment I submitted.

Because SIP and Q.850 have clearly defined meanings for their cause 
numbers, and this extension does not, I believe the text string should be 
maintained through IANA.

 From an IANA point of view, at 
http://www.iana.org/assignments/sip-parameters you can see the text string 
for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used 
if the SIP protocol were used in a 3326 Reason header. As IANA is where to 
first look up these things, I'm not sure why you have an issue with IANA 
having the same text string explaining what each cause is in the Preemption 
protocol of the Reason header. If the text string were removed in the IANA 
registration, there would be no clue there what each cause number meant.

This is not the case right now at 
http://www.iana.org/assignments/sip-parameters for all other SIP parameters.

I believe one of your concerns is the user learning/reading the reason in 
the Reason header within your domain, and I believe that is a local 
configuration decision.

In the document, I do not believe I ever made it a MUST, SHOULD, 
RECOMMENDED or even a MAY be presented to the user of the UA who is being 
preempted. I believe this is up to the implementation and local policy to 
show, or not to show.

>I suspect it requires a little better explanation on my part.
>
>based on, and follows everything in, RFC 3326. However, it doesn't make a 
>clear statement that the syntax follows what is defined in RFC 3326.
>
>As I read the syntax in Section 2 of RFC 3326, the reason header may 
>contain multiple reason-values (e.g., both SIP and Q.850) and for each 
>protocol may specify multiple reason-parameters (e.g., cause value and 
>text), and each is optional. The syntax defined in Section 2 allows the 
>use of a cause value without the accompanying text string, although the 
>examples don't ever show that.
>
>(However, the final paragraph of Section 2 of RFC 3326 implies that 
>multiple protocols are indicated by the use on multiple headers - 
>"multiple Reason lines" - not by putting multiple protocols into one header.)
>
>It seems that part of the problem is the way that the syntax was defined 
>in RFC 3326. While it implied that the text part is always used, the 
>formal definition shows it as optional.
>
>Concerning IANA registration, RFC 3326 only required the registration of 
>the protocols (SIP and Q.950) since all cause values and text strings were 
>defined elsewhere. This draft extends that model by requiring the 
>registration of more than the new protocol ("preemption"). It implies that 
>both cause values and text strings need to be registered, but this is not 
>clear. Rather than containing more description of the procedures for use 
>of these parameters, Section 7 needs explicit statements about IANA 
>registration requirements.
>
>Mike Pierce
>
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for new developments of core SIP

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.