[sipcore] More comments on location-conveyance-04

["Elwell, John" <[e-mail]>]

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:[e-mail]"

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