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 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
