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
- Re: [Sip] -resource-priority-05.txt: Comments and… Mpierce1
- Re: [Sip] -resource-priority-05.txt: Comments and… Janet P Gunn
- Re: [Sip] -resource-priority-05.txt: Comments and… Mpierce1
- Re: [Sip] -resource-priority-05.txt: Comments and… James M. Polk
- Re: [Sip] -resource-priority-05.txt: Comments and… David R Oran
- Re: [Sip] -resource-priority-05.txt: Comments and… Janet P Gunn
- Re: [Sip] -resource-priority-05.txt: Comments and… James M. Polk
- Re: [Sip] -resource-priority-05.txt: Comments and… Janet P Gunn
- Re: [Sip] -resource-priority-05.txt: Comments and… Mpierce1
- Re: [Sip] -resource-priority-05.txt: Comments and… Janet P Gunn
- Re: [Sip] -resource-priority-05.txt: Comments and… James M. Polk
- RE: [Sip] -resource-priority-05.txt: Comments and… Nguyen, An
- Re: [Sip] -resource-priority-05.txt: Comments and… Mpierce1
- Re: [Sip] -RP-05.txt: section 7.1 and (rough) con… James M. Polk