Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 31 Oct 2007 15:29:47 +0100

(As SIP WG chair)

Keeping up the pressure on you people out there doing the reviewing.

This is to announce a WGLC for 

"IANA Registration of New Session Initiation Protocol (SIP)
Resource-Priority Header Namespaces"

Contained in 

http://www.ietf.org/internet-drafts/draft-ietf-sip-rph-new-namespaces-00
.txt

The Working group last call is for two weeks until close of business on
Wednesday 14th November 2007.

Please submit any comments to the SIP list and to the editor.

I have solicited a number of independent reviews in parallel to this,
for which some have already been provided. These will be taken into
account in the WGLC.

Regards

Keith

_______________________________________________
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: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 31 Oct 2007 10:24:21 -0500

We support this. 

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2007 10:30 AM
To: IETF SIP List
Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00

(As SIP WG chair)

Contained in 

Regards

Keith

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 31 Oct 2007 14:01:33 -0400

I also support this, but I have some minor questions/nits.

 I am assuming that the second part of the namespaces (- 000009, -00000A, 
-00000B, etc.) are to be interpreted as "character strings" and not as 
hexadecimal numbers.  But at first glance they LOOK like hex numbers, so 
it might help future readers by pointing it out.

In the first full text paragraph of section 2, it says:
"A namespace from the above list will not be considered for 
   preferential treatment over another namespace unless local policy 
   has configured a SIP entity processing two messages (each with 
   different namespaces) as being equivalent (see section 8 of RFC 4412
   [RFC4412] for this detailed)."

I don't think this should be restricted to "a namespace from the above 
list".  This applies to  ANY namespace (whether one of the currently 
registered ones, one of the ones defined in this ID, or one to be 
standardized in the future).

And then the part that starts "The reality of this is..." would be clearer 
if it said  something like "For the case where they have not been defined 
as equivalent, the reality is..." (Otherwise, a reader might think that 
the antecedent for "this" was  "local policy has configured a SIP entity 
processing two messages (each with  different namespaces) as being 
equivalent".)

The rest of the paragraph talks about a message or call with dsn-000001.8 
not having preferential treatment over a message with dsn-000010.0.  I 
think it would be useful to state (rather than waiting for the reader to 
deduce) that  the call associated with the dsn-000010.0 RPH cannot be 
preempted by, nor can it preempt,  the call associated with the 
dsn-000001.8 namespace.

The next paragraph says:
"The dash '-' character is just like any other character, and is not 
   to be considered a delimiter in any official way within any 
   namespace here.  This MAY change in future efforts."

This use of "MAY" does not seem to be consistent with RFC 2119, so it 
should probably be "may" instead of "MAY". But even with a small "may" it 
is not clear what this means.  If this ID becomes an RFC, and then someone 
wants to register the namespace "A-B-C", what, if any impact will the 
statement "This may change in future efforts" have on the ability to 
register "A-B-C"?

Janet

"DOLLY, MARTIN C, ATTLABS" <[email-masked]> 
10/31/2007 11:24 AM

To
"DRAGE, Keith (Keith)" <[email-masked]>, "IETF SIP List" 
<[email-masked]>
cc

Subject
RE: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00

We support this. 

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2007 10:30 AM
To: IETF SIP List
Subject: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00

(As SIP WG chair)

Contained in 

Regards

Keith

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 31 Oct 2007 16:27:05 -0500

Janet

Comments in-line

At 01:01 PM 10/31/2007, Janet P Gunn wrote:

>  I am assuming that the second part of the namespaces (- 000009, 
> -00000A, -00000B, etc.) are to be interpreted as "character 
> strings" and not as hexadecimal numbers.  But at first glance they 
> LOOK like hex numbers, so it might help future readers by pointing it out.

from your examples above, all of
         "dsn-000009" and "dsn-00000A" and "dsn-00000B"

are singular, wholly separate and complete RPH namespaces.

The ' - ' is not a delimiter character, but is a character, as are 
the 0s and As and Bs.

>I don't think this should be restricted to "a namespace from the 
>above list".  This applies to  ANY namespace (whether one of the 
>currently registered ones, one of the ones defined in this ID, or 
>one to be standardized in the future).

this is a fair comment, and I will change the text to mean what you state here.

>And then the part that starts "The reality of this is..." would be 
>clearer if it said  something like "For the case where they have not 
>been defined as equivalent, the reality is..." (Otherwise, a reader 
>might think that the antecedent for "this" was  "local policy has 
>configured a SIP entity processing two messages (each 
>with  different namespaces) as being equivalent".)

I will make this clearer

>The rest of the paragraph talks about a message or call with 
>dsn-000001.8 not having preferential treatment over a message with 
>dsn-000010.0.  I think it would be useful to state (rather than 
>waiting for the reader to deduce) that  the call associated with the 
>dsn-000010.0 RPH cannot be preempted by, nor can it preempt,  the 
>call associated with the dsn-000001.8 namespace.

...unless local policy states this is the case (according to section 
8 of RFC 4412).

I will clean this up too

>This use of "MAY" does not seem to be consistent with RFC 2119, so 
>it should probably be "may" instead of "MAY".

no, I used "MAY" here to mean that there can be an update of this 
document in the future changing this statement (from the ' - ' not 
being a delimiter, to becoming a delimiter). This MAY is to let 
implementors know a future RFC can change this.

>But even with a small "may" it is not clear what this means.  If 
>this ID becomes an RFC, and then someone wants to register the 
>namespace "A-B-C", what, if any impact will the statement "This may 
>change in future efforts" have on the ability to register "A-B-C"?

For now, the  ' - ' (dash character) is just a normal character, and 
shouldn't be considered a delimiter, unless this future document 
changes this rule in such a way that reverse compatibility can be 
addressed successfully.

Does this help?