Re: [sipcore] More comments on location-conveyance-04
"Elwell, John" <john.elwell@siemens-enterprise.com> Tue, 09 November 2010 14:48 UTC
Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id BA63B28C0E8 for <sipcore@core3.amsl.com>;
Tue, 9 Nov 2010 06:48:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.495
X-Spam-Level:
X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104,
BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsbNu6XVpeH5 for
<sipcore@core3.amsl.com>; Tue, 9 Nov 2010 06:48:12 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com
[62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 46DC728C0D9 for
<sipcore@ietf.org>; Tue, 9 Nov 2010 06:48:11 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by
ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2234715;
Tue, 9 Nov 2010 15:48:35 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx
(Server) with ESMTP id E9CEB1EB82AB; Tue, 9 Nov 2010 15:48:35 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by
MCHP064A.global-ad.net ([172.29.37.63]) with mapi;
Tue, 9 Nov 2010 15:48:35 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "James M. Polk" <jmpolk@cisco.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Tue, 9 Nov 2010 15:48:31 +0100
Thread-Topic: [sipcore] More comments on location-conveyance-04
Thread-Index: Act/5JpEcUK7kFtlSVeC4kKsTnZfogAL0Zhw
Message-ID: <A444A0F8084434499206E78C106220CA023587EF29@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA02357AD05A@MCHP058A.global-ad.net>
<201011090803.oA983QR5020561@sj-core-1.cisco.com>
In-Reply-To: <201011090803.oA983QR5020561@sj-core-1.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sipcore] More comments on location-conveyance-04
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>,
<mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>,
<mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2010 14:48:13 -0000
James, Some further remarks below (rest removed): > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: 09 November 2010 08:03 > To: Elwell, John; sipcore@ietf.org > Subject: Re: [sipcore] More comments on location-conveyance-04 > > John > > Thanks for the review, you caught a lot of nits that were oversights > from the recent text cut-down. I'll go through them as best > I can in-line > > At 02:25 AM 11/5/2010, Elwell, John wrote: > >1. General > >This document seems to lack procedures sections for a UAC, a proxy > >and a UAS. Some of the procedures can be deduced from material in > >section 4 and elsewhere, but it is normal, for any SIP extension, to > >specify procedures for specific entities. > > [jmp] this has been the normal format in the past, and was as well up > until the -02 of this SIPCORE doc, but changed with the massive text > cut-down in -03 due to at least two factors > > - not simply having one operational behavior example (diagram) to > work from. You'll see that section 3 has 4 equally useful examples > that end up covering most, if not all, of this operational behavior > taken 1 example at a time instead of one SIP entity at a time. > > - the second factor was my new co-author's bent on seriously reducing > the paraphrasing or what other RFCs have said, sometimes dangerously > so (i.e., by not exactly matching what was written in those > other RFCs). [JRE] Section 3 comprises only examples. There is no normative language in section 3. In fact, as far as I can see, the only normative language is in section 4, with a couple of exceptions in sections 6 and 7. Section4 does not refer normatively to section 3 (and I don't think it should). What this means is that somebody implementing this just has to obey the MUSTs (and perhaps the SHOULDs) in section 4 (plus the couple in sections 6 and 7). So if there is anything we need a UAC, UAS or intermediary to do that is not specified in those sections, it most likely will not be done. If the group is happy that everything is covered in section 4 (+ section 6 and 7), then fine, but I am doubtful. It certainly doesn't follow conventional practice for SIP standards track RFCs. <snip/> > >18. Section 4.1: > >"However, if a SIP intermediary were to add location, even if > > location was not previously present in a SIP request, that SIP > > intermediary is fully responsible for addressing the > concerns of any > > 424 (Bad Location Information) SIP response it receives > about this > > location addition, and MUST NOT pass on (upstream) the > 424 response." > >How does the SIP intermediary know that the 424 refers to the added > >location, as opposed to the original location? If I understand > >correctly, a Geolocation header field in a 424 response denotes a > >corrected location, rather than a location in error, so comparison > >of sent and received Geolocation header fields would not work. > > [jmp] to quote Jon's response to me about this > > [JFP] This is one of many tangles introduced by the multiple location > object problem. We could either: a) add tons of cruft to support > this, or, b) merely say this is another defect of the poor design of > sending multiple location objects. The implication of 424 is that the > recipient has not gotten the location they need. The guidance here is > mainly for a case where the UAC did not provide location itself. [JRE] We at least need to say something about it. <snip/> > >20. Section 4.1: > >"The following table extends the values in Tables 2 and 3 of RFC 3261 > > [RFC3261]." > >I thought there was an agreement in the WG not to maintain tables 2 > >and 3 in RFC 3261. > > [jmp] hmmm... missed that memo [JRE] The rfc4244bis draft from sipcore is already in alignment with that decision, so it makes sense to apply it to location-conveyance too. <snip/> > >26. Section 4.3: > >If the request contains more than one locationValue, can there be > >more than one Geolocation-Error header field in the response, if > >more than one location is in error? However, my earlier comment > >about associating a Geolocation-Error with a particular > >locationValue would still be an issue. > > [jmp] this really gets sticky, because as I see it, this means there > needs to be a inserter= and an inserted-by= entities introduced > (taken out in -03), which creates a whole lot of cruft that really > makes this doc just hard to handle. [JRE] As I said above, we at least need to say something about this. <snip/> > >31. Section 4.3: > >"If the LS wants this message > > processed without this permission reset, it MUST choose another > > logical path (if one exists)." (two instances) > >What is meant by "another logical path"? > > [jmp] one that avoids this SIP server or chain of servers - because, > if the permission isn't reset, it'll be matched with a failure > repeatedly, right? [JRE] But how does the LS choose another path? And do we mean UAC rather than LS? <snip/> > >35. Section 5.1: > >"the SIP request uses a sips-URI [RFC3261]" > >Would RFC 5630 be a more appropriate reference? > > [jmp] neither Jon nor I think so [JRE] I can don't mind either way - was just asking the question. <snip/> John
- [sipcore] More comments on location-conveyance-04 Elwell, John
- Re: [sipcore] More comments on location-conveyanc… James M. Polk
- Re: [sipcore] More comments on location-conveyanc… Elwell, John