Subject: [sipcore] More comments on location-conveyance-04

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Nov 2010 09:25:59 +0100

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:[email-masked]"

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Nov 2010 02:03:25 -0600

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).

>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.

[jmp] we'll get that part right

>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.

[jmp] we'll get that part right, plus correct all the nits through 
your #9 below

>It might be worth pointing out that this case is identical to that in 3.1.

[jmp] sure

>Change "she should include" to "it should include".

[jmp] sure

>Change "In these cases" to "In this case", because I think there is 
>only one case described in the preceding text.

[jmp] sure

>    response, convey to her the best way to repair the request"

[jmp] sure

>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.

[jmp] sure, probably take out what's in 3.4

>"act as a B2BUA "

[jmp] sure

>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:
>This omits the semicolon in front of "routing-allowed". According to 
>the examples (which I think are correct) there should be a semicolon.

[jmp] we'll fix the ABNF for each header once we figure out what the 
parameters need to be, more on that later.

>"not appropriate for usage in the SIP Geolocation

[jmp] sure

>I assume we are talking about any scheme for use under absoluteURI, 
>since there is no other extension mechanism.

[jmp] this is going to be addressed in something Jon is going to 
propose very soon on the list before the Thursday meeting, so stay 
tuned for that

>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.

>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.

[jmp] this is probably my poor attempt at being doubly sure the 
default behavior of "=no" was adhered to. This really isn't necessary.

That said, if there is only ever one Geolocation header field in a 
SIP request, this really does go away.

>I thought there was an agreement in the WG not to maintain tables 2 

[jmp] hmmm... missed that memo

>"The Geolocation header field MAY be included in any request except 
>ACK or CANCEL and in any 424 responses to such requests."

[jmp] if we get rid of the table, this makes sense to me

>    PIDF-LO body parts MUST remain unchanged, never added to or deleted."

[jmp] sure

>                                 *(SEMI location-error-params)"

[jmp] this is an artifact of the -02 to -03 cut-down that I didn't 
catch. will get it now.

>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."

[jmp] sure

>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.

>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.

[jmp] sure

>I don't see any subsections.

[jmp] sure

>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.

[jmp] this is from a combining of the old "retry with same location 
data later (because the LR is busy)" and "retry with new or refreshed 
location data" error types. Yeah, I understand we probably should 
include a Retry-After header field, and just didn't get that into the 
-04 rev. It needs to be there in the final version though.

>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"?

[jmp] yeah, you're probably right here, this is a little too cavalier 
for a specification.

>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?

>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?

[jmp] this is also going to be addressed in that separate message to 
the list by Jon as he bakes his new idea about all this.

>field containing the reference.

[jmp] it's an artifact from a pre-03 version that needs to be addressed still.

>It seems to be more than a continuation of a discussion, it seems to 

[jmp] fair, we'll address this

>Would RFC 5630 be a more appropriate reference?

[jmp] neither Jon nor I think so

>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.

[jmp] fair

>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".

[jmp] yeah, to be fixed

>"Any node wanting to know where the target is located would 
>subscribe to the SIP presence event package [RFC 3856) at 
>sips:[email-masked]"

[jmp] right, poorly worded

>This probably should be Figure 2. However, neither Figure 2 nor 
>Figure 3 shows the message flow (SUBSCRIBE/200/NOTIFY/200).

[jmp] yeah, they're at a higher level (not layer) by showing the 
dereference as a single message exchange, and not the pair/pair 
exchange, which is directly related to which protocol does the 
dereferencing (e.g., HTTP is 2 messages, and SIP is 4 messages)

>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.

[jmp] again, this was a rounding of a corner that shouldn't have 
been, sorry, it will be fixed

>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.

[jmp] sure

>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.

[jmp] fair, but I think Jon's coming proposal will also affect this.

>It should be mentioned that it is the Response Codes registry that 

[jmp] sure

>It should be registered as simply "424 Bad Location Information".

[jmp] ok, I guess this is an old habit of proposing a code number and 
not assuming the number an ID picked also gets picked by IANA. That 
said, I can make this change.

>    "Header Field Parameters and Parameter Values"

[jmp] ok

>We need to state what the policy is for adding new values to the 

[jmp] I  believe right now I have up in section 8 part that a 
standards track doc is needed to extend any of this.

>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.

[jmp] again, this will likely be addressed in Jon's new proposal 
about URI schemes and option tags.

James

>John
>
>
>
>
>
>
>
>
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 9 Nov 2010 15:48:31 +0100

James,

Some further remarks below (rest removed): 

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: 09 November 2010 08:03
> To: Elwell, John; [email-masked]
> Subject: Re: [sipcore] More comments on location-conveyance-04
> 
> John
> 
[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/>

> mainly for a case where the UAC did not provide location itself.
[JRE] We at least need to say something about it.

<snip/>

> [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/>

> makes this doc just hard to handle.
[JRE] As I said above, we at least need to say something about this.

<snip/>

> if the permission isn't reset, it'll be matched with a failure 
[JRE] But how does the LS choose another path? And do we mean UAC rather than LS?

<snip/>

> [jmp] neither Jon nor I think so
[JRE] I can don't mind either way - was just asking the question.

<snip/>

John