Hi, I had a review of draft-ietf-sip-location-conveyance-08 and have the following comments to it. I have not followed up the email discussions for this draft so please apologize if any of my comments have already been raised.
1. Possible values within the inserted-by parameter What kind of value should the UAC enter into the "inserted-by" parameter if it does not have a hostname ? Is e.g. the local IP address of the UAC OK ? The BNF syntax refers to "host-id" when describing the contents of the "inserted-by" parameter. However I did not find anywhere any formal BNF definition to the "host-id" (either in this draft or RFC 3261), thus it is not clear if it only refers to a hostname or could it also refer to e.g. an IP address or some other cryptographically constructed random ID allocated by the UAC. 2. Handling of 424 responses In my opinion the handling the 424 responses is not well specified: UAC: The Geolocation-Error has a header parameter indicating which entity inserted the location pertaining to this error. This is in the form of a host-id. A UAC receiving this 424 should review this "inserter=" locationErrorValue parameter to see if it indicates this UAC. If it does not, the 424 should be ignored. First of all the Geolocation-Error header might contain multiple locationErrorValue entries. It is not clear in the normative text for UAC that the UAC is expected to search through all of those to check if it can find any entries targetted to itself. Further on if there is no entries for the UAC, shall the UAC really ignore the 424 and continue retransmitting the request or handle it as 4xx response and stop retransmissions ? What if it was the proxy to insert Geolocation header into the request and the UAS would return 424 response ? There is no normative text for the proxy to take this response into account even if the Geolocation-Error header would refer to the proxy. 3. Usage of geolocation tag in the Supported header Usage of the geolocation tag in the Supported header is not specified according to the guidelines of RFC 3261. There were similar issues raised for SIP Outbound recently and the agreement was to fix them: http://www1.ietf.org/mail-archive/web/sip/current/msg20045.html RFC 3261: If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. draft-ietf-sip-location-conveyance-08: Whenever a UA wants to indicate support for this SIP extension, the geolocation option tag is included in a Supported header of the SIP message. The UAC supporting this extension MUST include a Supported header with the geolocation option tag. The geolocation option-tag is inserted in a Supported header by a UAC to provide an indication of support for this extension. The presence of the geolocation option tag in a Supported header without a Geolocation header field in the same message informs a receiving SIP element the UAC understands this extension, but it does not know or wish to convey its location at this time. Certain scenarios exist (location-based retargeting) in which location is required in a SIP request in order to retarget the message properly. This affects how a UAS or SIP server processes to such a request. The semantics of the geolocation tag within the Supported header seems to be vaguely defined. The presence of this tag does not indicate the UAS (or proxy) any extensions that the server could apply to its response. According to RFC 3261 that would however be the reason why to include an option tag into the Supported header of a request. All the use cases given in the draft for the geolocation tag justify its usage within the Require header but there seems to be no clear reason why the UAC would add it into the Supported header of a request. Support for the extension can also be inferred from the presence of Geolocation header. If it is not present but the a proxy would require it for retargeting, the correct behaviour would be the proxy to send 421 Extension Required response. A UAS MAY include a geolocation option-tag in the Supported header of a response, indicating if does understand this extension. Similarily for the UAS no clear reasons exist why to include the Supported header into its response. Nit: 4.1 Location-by-value Geolocation: <cid:[email protected]> --boundary1 Content-Type: application/pidf+xml Content-ID: [EMAIL PROTECTED] In Geolocation header the Content ID begins with "target123" even if within the MIME entity the ID begins with "alice123". Regards, Erkki Koivusalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
