Janet
Comments in-line
At 01:01 PM 10/31/2007, Janet P Gunn wrote:
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.
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.
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).
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
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".
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?
Janet
"DOLLY, MARTIN C, ATTLABS" <[EMAIL PROTECTED]>
10/31/2007 11:24 AM
To
"DRAGE, Keith (Keith)" <[EMAIL PROTECTED]>, "IETF SIP List"
<[email protected]>
cc
Subject
RE: [Sip] WGLC for draft-ietf-sip-rph-new-namespaces-00
We support this.
-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED]
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)
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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
