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