[sipcore] More comments on location-conveyance-04
"Elwell, John" <john.elwell@siemens-enterprise.com> Fri, 05 November 2010 09:01 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 6D4833A6452 for <sipcore@core3.amsl.com>; Fri, 5 Nov 2010 02:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level:
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 D1NRgLgV5CTD for <sipcore@core3.amsl.com>; Fri, 5 Nov 2010 02:01:34 -0700 (PDT)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 52B353A63EB for <sipcore@ietf.org>; Fri, 5 Nov 2010 02:01:34 -0700 (PDT)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2183785 for sipcore@ietf.org; Fri, 5 Nov 2010 09:26:02 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 20F6623F0278 for <sipcore@ietf.org>; Fri, 5 Nov 2010 09:26:02 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Nov 2010 09:26:02 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Fri, 05 Nov 2010 09:25:59 +0100
Thread-Topic: More comments on location-conveyance-04
Thread-Index: Act8wxOA6LCr6AG7RhuTO8Kg78vJ6A==
Message-ID: <A444A0F8084434499206E78C106220CA02357AD05A@MCHP058A.global-ad.net>
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: [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: Fri, 05 Nov 2010 09:01:36 -0000
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. 2. As I have recently said about rfc4244bis, we should use "header field" instead of "header" where appropriate throughout the document. My reasoning has already been stated on this list in the context of rfc4244bis. 3. As I have recently said about rfc4244bis, we should avoid using the passive voice in normative statements. A normative statement forces us to make it clear which entity is required to comply with the statement. I have not picked out specific instances, but there are many. 4. Abstract: "where SIP intermediaries make routing decisions based upon the location of the user agent client." I think "user agent client" should be changed to "target". 5. Section 1: "Location Objection" Sustained! Change it to "Location Object". 6. Section 2: "to deliver URIs point to " Change to: "to deliver URIs pointing to " 7. Section 3.2: "the LS provides the location value to Bob instead of Alice directly." I think it should say: "the LS provides the location value to Bob directly instead of to Alice for conveyance to Bob." 8. Section 3.3: "In this case, the intermediary acts as a Location Recipient." This is effectively a repetition of the 3rd sentence in the paragraph - delete. 9. Section 3.3: "In this case, the intermediary does not act as a Location Recipient." It might be worth pointing out that this case is identical to that in 3.1. 10. Section 3.4: "Thus, it must inform her user agent what location she should include in any subsequent SIP request that contains her location. " Change "she should include" to "it should include". 11. Section 3.4: "In these cases, the intermediary can reject " Change "In these cases" to "In this case", because I think there is only one case described in the preceding text. 12. Section 3.4: "the intermediary can reject Alice's request, through the SIP response, convey to her the best way to repair the request" Add "and" after "Alice's request" (before the comma). New text: "the intermediary can reject Alice's request and, through the SIP response, convey to her the best way to repair the request" 13. Section 3.4: "If desired, intermediaries may furthermore allow both Alice's internally generated location, as well as the SIP intermediary's determination of where Alice, to appear in the same SIP request (the resubmitted one), and permit that to be forwarded to Bob. This case is discussed in more detail in section 4.2 of this document." If I understand correctly, this case is also covered in 3.3. There is no need to cover the same case in both sub-sections. Delete one of them. 14. Section 3.4: "act a B2BUA " Change to: "act as a B2BUA " 15. Section 4.1: I am aware of separate discussions ongoing concerning the ABNF, but depending on what we end up with, we should ensure that the following error is somehow fixed: "routing-param = "routing-allowed" EQUAL "yes" / "no"" This omits the semicolon in front of "routing-allowed". According to the examples (which I think are correct) there should be a semicolon. 16. Section 4.1: "not appropriate for usage the SIP Geolocation header." Change to: "not appropriate for usage in the SIP Geolocation header." 17. Section 4.1: "Other URI schemas used in the location URI MUST be reviewed against the RFC 3693 [RFC3693] criteria for a Using Protocol." Who must conduct this review? Use active voice. I assume we are talking about any scheme for use under absoluteURI, since there is no other extension mechanism. 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. 19. Section 4.1: "If a routing-allowed parameter is parsed as set to "=yes", an implementation MUST parse the rest of the SIP headers for another instance of the Geolocation header value to determine if there is another instance of the routing-allowed parameter set to "=no". If this is the case, the behavior MUST be to process the "=no" indication only, and ignore the "=yes"." This is a rather unusual requirement, and may be obviated by proposed changes to the ABNF. If not, my concern is that SIP parsers do not necessarily look out for conflicting bits of information, and might just make the first or last instance available to the application. Also it seems a bit unnecessary to specify this, since it is forbidden to add a second routing-allowed parameter, so if two occur it is an invalid message, and perhaps unreasonable to expect a defined behaviour. 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. 21. Section 4.1: "The Geolocation header field MAY be included in any one of the optional requests by a UA. " If we get rid of the table, in accordance with the previous comment, this should say: "The Geolocation header field MAY be included in any request except ACK or CANCEL and in any 424 responses to such requests." 22. Section 4.2: "All respects of the Geolocation and Geolocation-Error headers and PIDF-LO(s) MUST remain unchanged, never added to or deleted." This should say: "Geolocation and Geolocation-Error header fields and PIDF-LO body parts MUST remain unchanged, never added to or deleted." 23. Section 4.2: "In this scenario, a SIP intermediary is informing the upstream UA which location to include in the next SIP request. " Two scenarios are mentioned in the preceding text. Should say: "In the latter scenario..." 24. Section 4.3: "Geolocation-Error = "Geolocation-Error" HCOLON locationErrorValue locationErrorValue = location-error-arg location-error-arg = location-error-code *(SEMI location-error-params)" The is an unnecessary intermediate step here. Why not: "Geolocation-Error = "Geolocation-Error" HCOLON locationErrorValue locationErrorValue = location-error-code *(SEMI location-error-params)" 25. Section 4.3: "The following table extends the values in Table 2&3 of RFC 3261 [RFC3261]." Same comment as for the previous table. The table could be deleted. This would require a small change to the sentence after the table:, e.g.: "The Geolocation-Error header field MAY be included in any response to a SIP request containing a Geolocation header field locationValue." 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. 27. Section 4.3: "The SIP requests included in table 2 above are the ones allowed to optionally contain the Geolocation header field (see section 4.1)." Table 2 as it stands doesn't list any requests - only responses. However, if my earlier comment about removing the table is accepted, this sentence would need attention anyway. In fact it appears to be redundant - I don't think it conveys any new information. Delete it. 28. Section 4.3: "The following subsections provide an initial list of location based errors for any SIP non-100 response" I don't see any subsections. 29. Section 4.3: "Geolocation-Error: 200 "Retry Location Later ..." Should this be accompanied by a Retry-After header field? Under what circumstances might an LR determine that it can't use the present location but could use an updated location sometime in the future? I fail to see the motivation for this error code. 30. Section 4.3: "with device updated location" I assume this means the device must update the location. But how does the LR know that the location came from the device, as opposed to some other location generator? Suggest delete "device"? 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"? 32. Section 4.4: "This document creates and registers with the IANA one new option tag: "geolocation". This option tag is to be used, as defined in [RFC3261], in the Require, Supported and Unsupported header fields." There should be some statement about what the option tag means, i.e., support for the SIP extensions specified in this document. However, I have a more fundamental concern. There are no procedures anywhere for using this option tag in Supported, Unsupported or Require. If it is not used, why is it needed? Inclusion of the Geolocation header field implies support by the UAC. Sending a 424 or Geolocation-Error implies support by the UAS. Are there other cases where support needs to be known (e.g., in a request without Geolocation or in a 200 response without Geolocation-Error)? If we don't have any uses for the option tag, why define it? 33. Section 4.5: "In the case where a location recipient sends a 424 response and wishes to communicate suitable location by reference rather than by value, the 424 MUST include a content-indirection body per RFC 4483." Why is this needed? A 424 response can contain a Geolocation header field containing the reference. 34. Section 4.6: "The following is part of the discussion started in Section 3 ..." It seems to be more than a continuation of a discussion, it seems to be specification. 35. Section 5.1: "the SIP request uses a sips-URI [RFC3261]" Would RFC 5630 be a more appropriate reference? 36. Section 5.1: " An assumption can be made that SDP is the other message body part. " This is just an example. We don't need tell the reader to make an assumption - just state that in this example SDP is the other body part. 37. "The "cid:" eases message body parsing by disambiguating the MIME body that contains the location information associated with this request." Easing parsing and disambiguating are two different properties - the one doesn't rely on the other. Should say "eases message body parsing and disambiguates multiple parts of the same type". 38. Section 5.1: "Any node wanting to know where user "target123" is would subscribe to that user at server5 to dereference the sips-URI" I think this should say: "Any node wanting to know where the target is located would subscribe to the SIP presence event package [RFC 3856) at sips:target123@server5.atlanta.example.com" 39. In the same sentence: "(see Figure 3 in section 3 for this message flow )" This probably should be Figure 2. However, neither Figure 2 nor Figure 3 shows the message flow (SUBSCRIBE/200/NOTIFY/200). 40. Section 6: "Implementations of this SIP location conveyance mechanism MUST adhere to the guidance given in RFC3693 and its successors " I assume by "and its successors" we are specifically referring to [ID-GEOPRIV-ARCH]. However, according to text earlier in the paragraph, and according to the architecture draft itself, it only updates RFC 3693, it is not a successor. So either say "all updates" or specifically mention the architecture draft. 41. Section 8.1: "The SIP Geolocation Header Field is created by this document, with its definition and rules in Section 4.1 of this document, and should be added to the IANA sip-parameters registry, in the portion titled "Header Field Parameters and Parameter Values" ." This provides a single IANA instruction where really it should provide two. It should update the Header Fields registry with Geolocation and should update the Header Field Parameters and Parameter Values registry with routing-allowed. 42. Section 8.2. "The SIP option tag "geolocation" is created by this document, with the definition and rule in Section 4.4 of this document, to be added to the IANA sip-parameters registry." Assuming we retain the option tag (see an earlier comment), it should be mentioned that it is the Options Tags registry that is to be added to. 43. Section 8.3: It should be mentioned that it is the Response Codes registry that is added to. 44. Section 8.3: "Response code: 424 (recommended number to assign) Default reason phrase: Bad Location Information " It should be registered as simply "424 Bad Location Information". 45. Section 8.4: "The SIP Geolocation-error header field is created by this document, with its definition and rules in Section 4.3 of this document, to be added to the IANA sip-parameters registry, in the portion titled "Header Field Parameters and Parameter Values" Same comment as on 8.1. 46. Section 8.5. We need to state what the policy is for adding new values to the error codes registry. 47: "8.6 IANA Registration of Location URI Schemes" Do we really need a registry for this? URI scheme names are already registered elsewhere. Also the ABNF doesn't provide an extensibility mechanism. Or is "absoluteURI" meant to be the extension mechanism? However, there is nothing in section 4 that limits schemes used under absoluteURI to being only those defined in this registry, so it is unclear what purpose the registry serves. 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