Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)

"James M. Polk" <jmpolk@cisco.com> Tue, 16 November 2004 18:58 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29632 for <sip-web-archive@ietf.org>; Tue, 16 Nov 2004 13:58:30 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8ZN-0004v5-9I for sip-web-archive@ietf.org; Tue, 16 Nov 2004 14:00:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8NJ-0006It-Ms; Tue, 16 Nov 2004 13:48:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8Hr-00052g-6m; Tue, 16 Nov 2004 13:42:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28447; Tue, 16 Nov 2004 13:42:41 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8K4-0004WZ-Us; Tue, 16 Nov 2004 13:45:02 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Nov 2004 10:57:08 -0800
X-BrightmailFiltered: true
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAGIfqw0022526; Tue, 16 Nov 2004 10:41:52 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA24435; Tue, 16 Nov 2004 10:42:04 -0800 (PST)
Message-Id: <4.3.2.7.2.20041116120434.03868770@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 16 Nov 2004 12:42:11 -0600
To: Mpierce1@aol.com, jgunn6@csc.com, oran@cisco.com
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)
In-Reply-To: <1e6.2ef6420a.2ecb901f@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: An.Nguyen@ncs.gov, sip@ietf.org, sip-bounces@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433

comments in-line

At 12:17 PM 11/16/2004 -0500, Mpierce1@aol.com wrote:
>In a message dated 11/15/2004 11:39:06 PM W. Europe Standard Time, 
>jmpolk@cisco.com writes:
>
>
>> >The .03 draft (and I think also the .04 draft) had a paragraph that said
>> >    "Namespaces do not describe how they relate to other existing
>> >    namespaces, as each namespace is independent of other registrations."
>> >
>> >It doesn't seem to be in .05
>>
>>see (the new) section 7.1 about the warnings of multiple namespaces
>
>I don't read anything in 7.1 as saying what the previous versions said.

correct

I removed any comment about dependency because there may be a dependency in 
a domain - based on local policy, and this document should not make any 
comment that could contradict local policy.

>What I think is needed is a very clear statement something like "neither 
>this document nor namespaces specify the interrelationship or interworking 
>between namespaces, such as mapping from one namespace to another at 
>domain boundaries".

What you have above is unnecessary. If the document does not state a 
dependency, there is not one defined.

>That was my understanding of the previous agreement.

what previous agreement?


>As a result, the first bullet in Section 7.1, which states "There MUST be 
>one order of priorities a SIP element has to process to", while talking 
>about multiple namespaces in a message, seems to be wrong (or misunderstood),

It is not wrong, and I'm sorry if it is misunderstood.

The section is about *ordering* of namespaces, and gives clear examples of 
ordering that is in line with this specification (to be) and clear examples 
of ordering that is not allowed in this specification (to be).

>  since it seems to require something about the relationship.

no it does not. It either does, or it does not - there is no "seems".

>In fact the example following this bullet list is trying to say something 
>about the "acceptable" ways that the SIP element may process multiple 
>namespaces.

That it does, as it is a violation to reorder priority values just because 
another namespace is introduced. It primarily gives examples of how 
multiple namespaces can be interleaved in acceptable and unacceptable orders.

>The part about what is "not acceptable" is not needed.

I do not agree

>The examples of incorrect order within each individual namespace are not 
>allowed even without multiple namespaces.

Well, how many coders have you spoken or emailed with that understood this 
from the previous version(s)? I'll bet none. I have fielded many such 
communications - and in each given them an explanation just like what is in 
7.1 and it becomes clear fairly quickly what was meant in previous versions 
(that was not explained well enough).


>Since the document should say that it does not address interworking 
>between namespaces, it should not contain this material.

giving examples to clarify a known area of confusion is a good thing - and 
will stay in the document.


>I don't know what the second bullet is trying to say.

that there can be more than one namespace in a message, and have 1 or more 
of these additional namespaces ignored


>The third bullet is obvious, I thought, according to the rules of SIP. If 
>not, this statement could be worded better.

Again, fielded a lot of questions about this, and put it in to clarify to 
coders that the order of RP headers in a message does not determine which 
matter. I reworded it already for the next version.


>Section 7.1 should be deleted completely and replaced with a single 
>statement something like I proposed above.

it will not be deleted, though it might be modified to add or clarify meaning


>( I guess this will start a long series of e-mails on what I find wrong in 
>-05.)

You, have an opinion?

tell me it isn't so   ;-)


>Mike Pierce


cheers,
James

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


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip