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

"James M. Polk" <> Tue, 09 November 2010 08:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCBFE3A6886 for <>; Tue, 9 Nov 2010 00:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yI6I3dIw1J5J for <>; Tue, 9 Nov 2010 00:03:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B6ED53A67E5 for <>; Tue, 9 Nov 2010 00:03:04 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAHqP2EyrR7Ht/2dsb2JhbACiHnGhAptmgnyCTgSEWA
X-IronPort-AV: E=Sophos;i="4.59,174,1288569600"; d="scan'208";a="616910939"
Received: from ([]) by with ESMTP; 09 Nov 2010 08:03:28 +0000
Received: from ([]) by (8.13.8/8.14.3) with ESMTP id oA983QR5020561; Tue, 9 Nov 2010 08:03:27 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 09 Nov 2010 02:03:25 -0600
To: "Elwell, John" <>, "" <>
From: "James M. Polk" <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [sipcore] More comments on location-conveyance-04
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Nov 2010 08:03:06 -0000


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

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

[jmp] sure

>10. Section 3.4:
>    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".

[jmp] sure

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

[jmp] sure

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

[jmp] sure

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

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

>14. Section 3.4:
>"act a B2BUA "
>Change to:
>"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:
>"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.

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

>16. Section 4.1:
>"not appropriate for usage the SIP Geolocation
>    header."
>Change to:
>"not appropriate for usage in the SIP Geolocation
>    header."

[jmp] sure

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

[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

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

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

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

>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

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

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

>22. Section 4.2:
>    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."

[jmp] sure

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

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

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

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

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

[jmp] sure

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

[jmp] sure

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

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

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

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

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

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

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

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

[jmp] fair, we'll address this

>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

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

[jmp] fair

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

[jmp] yeah, to be fixed

>38. Section 5.1:
>    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 

[jmp] right, poorly worded

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

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

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

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

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

[jmp] sure

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

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

>43. Section 8.3:
>It should be mentioned that it is the Response Codes registry that 
>is added to.

[jmp] sure

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

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

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

[jmp] ok

>46. Section 8.5.
>We need to state what the policy is for adding new values to the 
>error codes registry.

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

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

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


>sipcore mailing list