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

From: [email-masked]
Date: Mon, 6 Jun 2005 10:12:17 EDT

In a message dated 6/2/2005 6:10:09 PM Eastern Daylight Time, 
[email-masked] writes:

> 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 guess I didn't explain my concern well enough. It isn't the issue of 
notifying the user of something they shouldn't know in our domain. The "Generic 
Preemption" was added to deal with this.

I have no problem with the (default) text string being registered with IANA 
for each defined preemption cause as was done for each SIP response code. The 
concern is that the IANA considerations section does not make it clear that 
this is what IANA is expected to do.

I don't understand why this is called the "default" text. It would seem that 
any device could put in any text string it wanted, for example, the same thing 
in another langauage. I believe RFC 3261 is rather vague on this issue. While 
the ABNF requires that a Reason-phrase be included in every message and it 
provides "default" text for each and includes it in the IANA registration, I 
don't believe it requires that this exact text string be used.

My comment is mostly that there appears to be a conflict between the text in 
this draft and the formal syntax definition in RFC 3326. I don't know which is 
correct. It would seem to me that, if this new preemption cause is used, that 
the numeric cause value is mandatory and the text string is optional. Neither 
RFC 3326 nor this draft says that. The formal definition in RFC 3326 says 
both are optional. This draft indicates that both are required.

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 questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 06 Jun 2005 18:52:47 -0500

comments lower in the message

At 10:12 AM 6/6/2005 -0400, [email-masked] wrote:
>I guess I didn't explain my concern well enough.

I think I now understand your original comment differently

>It isn't the issue of notifying the user of something they shouldn't know 
>in our domain. The "Generic Preemption" was added to deal with this.

yes

>I have no problem with the (default) text string being registered with 
>IANA for each defined preemption cause as was done for each SIP response 
>code. The concern is that the IANA considerations section does not make it 
>clear that this is what IANA is expected to do.

fair point - and one I have asked our chair to clarify for the revision of 
this document.

>I don't understand why this is called the "default" text.

well... because the text string is optional, and the text can be something 
other than the exact string listed as the default in this document.

>It would seem that any device could put in any text string it wanted, for 
>example, the same thing in another langauage.

yes, but this is guidance - ala "if you use a text string, we recommend 
this one for consistency"

>I believe RFC 3261 is rather vague on this issue. While the ABNF requires 
>that a Reason-phrase be included in every message and it provides 
>"default" text for each and includes it in the IANA registration, I don't 
>believe it requires that this exact text string be used.

nope it doesn't, you're right, and that is why the word "default" is used 
for guidance reasons. The doc specifies the exact reason for each code, but 
the string can be some variant. I can give more explanation in that part of 
the document to this affect.

>My comment is mostly that there appears to be a conflict between the text 
>in this draft and the formal syntax definition in RFC 3326. I don't know 
>which is correct.

I attempted to take the 3326 text a bit further without overstepping the 
gist of the RFC.

>It would seem to me that, if this new preemption cause is used, that the 
>numeric cause value is mandatory and the text string is optional.

yes, as long as the new cause code act exactly as is specified in that 
extension RFC, and there is a default text string to give *some* guidance 
(which can be omitted or changed per domain).

>Neither RFC 3326 nor this draft says that. The formal definition in RFC 
>3326 says both are optional. This draft indicates that both are required.

I didn't mean to imply the text string is required - I would have used 
SHALL if I meant that. I apologize for the mixed meaning there.

I will clarify that the text string is optional in the document, but a 
guidance/default string is needed for IANA registration. I will add that 
this string can be something other than the exact string given in the doc 
per cause value. Is this agreeable?

>Mike Pierce

cheers,
James

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