James, Thanks for your responses. Please see my further remarks below.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of James M. Polk > Sent: 26 November 2008 18:59 > To: Elwell, John > Cc: SIP List > Subject: Re: [Sip] Comments on location-conveyance-12 > > John > > Thanks for the excellent review. I have comments in-line below > > At 10:38 AM 11/26/2008, Elwell, John wrote: > >Apologies that these comments are rather late: > > > >Technical comments: > > > >1. Why do we permit Geolocation in a PRACK request? > > because I couldn't come up with a good enough reason to prohibit it > in any Method except ACK and CANCEL. My preference is to not allow > it in a BYE either, but I've received more than one comment that this > shouldn't be prevented - as there may be a use down the road that we > cannot foresee now. > > >Suppose the UAS > >considers the location to be essential, but has some problem > with it and > >returns a 424 response. Where does this leave the reliable > provisional > >response that the PRACK request was supposed to be acknowledging? > > The thinking is that any 424 rejection, where Location is mandated > (i.e., essential), overrides subsequent requests (i.e., transactions) > within the same Call-ID until the problem about the Location (it's > bad, it's invalid, it's not present, it can't be parsed, it can't be > dereferenced, etc) is resolved. > > Is this something you do not agree with. > > Removing PRACK from being allowed to carry a Geolocation header is > easy, I just need a good enough reason to do it. [JRE] My feeling is that we should either remove PRACK or add some explanation of how a UAC should behave if it receives a 424 to a PRACK request (taking into account that there is an unacknowledged reliable 18x outstanding). I will go with the majority as to which of these two options we take. > > >A > >similar problem has been discussed with SDP in a PRACK request, and a > >less-than-perfect solution has been found. However, for SDP we had to > >find a solution because SDP has been permitted in a PRACK > request since > >RFC 3262. With Geolocation we have the opportunity to > disallow it in a > >PRACK request, thereby avoiding the problem. > > > >2. In the example in 5.1: > >";inserted-by="[EMAIL PROTECTED]"" > >I don't think [EMAIL PROTECTED] is a valid hostport. > > I coped this from what's allowed in a Via header, therefore I believe > it should be. [JRE] From my understanding of the ABNF for hostport, it cannot contain "@". I don't know why you think this is allowed in a Via header - I could not find any evidence. > > >We could > >reduce it to "atlanta.example.com", which is the same as the > domain part > >of the From URI, but then it would not be possible for a recipient to > >distinguish whether it was inserted by the UAC or the proxy > >[EMAIL PROTECTED] proxy. > > Exactly the problem with not identifying the exact host who inserted > the location in the first place. This is an identifier to a > particular host that inserted a particular location to inform the > location recipient that determined the location was bad in order to > target the return e2e message at a particular host in the signaling > path that their location was considered bad and understand that host > (and no other host) need pay attention to the error code in the > locationErrorValue. [JRE] Depends on resolution of the previous comment. > > >Moreover, if both the UAC and the proxy > >insert a location with the same inserted-by > > this would not happen, if this spec is followed. Each inserter= would > be different. Pragmatically, if they are not, then each will have to > act according to the error code. [JRE] Depends on resolution of the earlier comment. > > >, they would not be able to > >distinguish which error code relates to the location they inserted. > > yep, but that's their problem. Each host needs to identify themselves > uniquely for this reason, otherwise they suffer not knowing which > host this error is for, but will have to act as if it were both hosts. > > >In > >this particular case LbyV is used, so location must have > been inserted > >by the UAC. Wouldn't it be more appropriate to use the UAC's own host > >name (i.e., from its contact URI) > > I mentioned this is copied from the Via header, so this ought to be > good enough. Let me know if it is not. [JRE] See above. > > >, or if it doesn't have one, its IP > >address? > > IP addresses will be overwritten by SBCs, pragmatically, so I'm not > sure this is enough of an identifier, do you? > > > Of course, if the IP address is behind a NAT it might not be > >unique, and I suppose there is potential for conflict if the UAC is > >behind two NATs. > > yes - this is a concern > > >Have there been any discussions on this? > > yes > > >It might > >require more than just fixing the example - it might require > more text > >on UAC behaviour to address this issue. > > given what you and I have said above, what merger of text > would you suggest? [JRE] I need agreement on what can go in the inserted-by field before I can make any specific proposals. > > > >There are other instances in the document of inappropriate > inserted-by > >values. > > I believe, though, that they are all consistent now. Any change will > be global also. [JRE] Yes, I know they are consistent, but I think they are wrong. > > > >3. "If a UAC has already conveyed location in the original > request of a > > transaction, and wants to update its location information (for > > whatever reason) after the original request is sent, or after a > > dialog is created (regardless of how the UAC conveyed location > > previously, as an LbyV or LbyR) - this is done by a UAC > sending an > > UPDATE request [RFC3311]" > >I think we should change "transaction" to "INVITE dialog usage". > >"Transaction" is certainly wrong. The question is whether we > change it > >to "dialog" or "INVITE dialog usage". I think UPDATE applies only to > >INVITE dialog usages. > > I'll accept your correction, and change the text to "INVITE dialog > usage" to be completely clear here. > > > >4. "Unless stated otherwise by future standards-track > publication(s), a > > LbyR URI only has meaning within the Geolocation header field and > > MUST NOT appear in any other SIP header field." > >This is a requirement on the UAC or proxy, yet it appears in > the section > >on UAS behaviour. > > yes - to guide the UAS to not pay attention to a LbyR URI anywhere > else than a Geolocation header. The point here is to disallow usage > of a Location URI in any header except the Geolocation header (i.e., > not stuffed into another header). [JRE] If we are making a normative statement about what a UAC or proxy can insert in other header fields, that should appear in the section dealing with UAC or proxy behaviour respectively. If we are just reminding the reader that other header fields cannot carry a LbyR URI, we should not use RFC 2119 language. For the latter case, just changing "MUST NOT" to "should not" would suffice. > > > >5. "A > > "used-for-routing" parameter MUST NOT ever be removed from a > > locationValue in a request." > >This appears in the section on UAS behaviour, yet I don't > see that it is > >relevant to a UAS. > > this provides the UAS with strong guidance that a locationValue has > been used to make a routing decision. Since more than one > locationValue can be in a request, having this indication inside each > locationValue that was used for routing decisions gives the UAS an > indication - call it a history - of the path of the request > towards the UAS. [JRE] If we are trying to assist the UAS implementer, we should not use RFC 2119 language. We should rephrase something like "A "used-for-routing" parameter, once inserted by an entity, should not be removed by any downstream entity and should reach the UAS". > > From a historical point of view, this provides an after-the-fact > account of how each routing entity made its decision to route the > request. This was requested specifically from the emergency calling > folks so they can figure out if a particular routing entity made a > bad decision - optimistically believing they can modify routing > decisions for future/similar locations in requests. [JRE] Yes, I understand the reason for it - it just needs to be reworded. > > >The UAS is the recipient, and any passing on of > >location information is outside the scope of this document. > Also I don't > >see how it is testable. If we need to make such a statement, > I think it > >should be in the proxy section. > > > >6. "Additional locationValues inserted into a request SHOULD > be placed > > the order they were generated, and not rearranged." > >Again we have a normative statement on UAC/proxy behaviour in the > >section dealing with UAS behaviour. > > this is specific to the answer in bullet #5, to give the UAS a path > of entities the request passed through, in order, so the UAS can > learn which location the request was routed to first, then which was > second <and so on>. [JRE] So again, RFC 2119 language should not be used. We should say something like "Multiple locationValues received in a request will appear in the order in which they were inserted by upstream entities." > > > >7. "Individual header parameters in any received > locationValue MUST NOT > > be modified or deleted in transit to the ultimate destination." > >Again this appears in the section on UAS behaviour, and we should not > >specify the transiting of location information by a UAS to elsewhere, > >since that is outside the scope of this document. > > but this is a *hint* at those nasty things called B2BUAs and SBCs... [JRE] This might not be clear to the reader. Elsewhere we have a statement "In the spirit of informing implementers of B2BUAs and SBCs, each server type really should adhere to the above proxy guidance with respect to the "Routing-allowed" header parameter" If we had similar statements about other aspects of proxy behaviour that B2BUAs should adhere to, I think that would be better. Then the sentence on which I commented could be deleted. > > > >8. "A UAS MUST be prepared to receive subsequent location > updates from > > the UAC, either LbyV or LbyR (regardless of how the UAS received > > location previously from this UAC). The UAC will convey location > > using the UPDATE [RFC3311] method to the UAS." > >See also my earlier comment about INVITE dialog usages. I think this > >paragraph too is only concerned with updates within the context of an > >INVITE dialog usage. > > I'll make the same correction to "INVITE dialog usages" > > > >9. "This document makes it clear that if when there are more than one > > location, each in the same PIDF-LO MUST be about the same Target > > (identifier) and point at the same position on the earth." > >I think "MUST" should be "must", because the normative requirement is > >stated elsewhere. > > ok > > I'll also correct the "...that if when there..." part of the > sentence, given that it doesn't make much sense (oops). > > >This section is concerned only with UAS behaviour, so > >cannot make normative statements applicable to the UAC or a proxy. > > > >10. "All other entities MUST > > ignore any locationErrorValue not directed towards them." > >Again, this is in the section on UAS behaviour, so we can't make > >normative requirements on other entities. Change "MUST" to "must" or > >"are required to". > > good suggestion > > > >11. "The above example says that the Location Recipient is > > server42.example.com, and this entity believes it cannot > route this > > message without knowing the "inserter="'s location." > >server42.example.com could be a UAS - there is nothing to say it is a > >proxy. Since a UAS cannot route, then change "route" to > "handle", which > >is more general purpose. > > good suggestion > > > >12. "o there MUST NOT be more than one locationErrorValue > to the same > > "inserter=" in the request." > >and then later: > >"The > > error codes destined for the same inserter MUST NOT > contradict the > > meaning of the problem the Location Recipient had with a > particular > > locationValue." > >I found these two statements contradictory. > > yeah - thanks for catching this. > > This is an artifact from the old way I proposed doing the location > error messages to the newer (and simpler) way of doing location error > messages. The former text is true, and the latter needs to be > modified or deleted. [JRE] Good. > > >The first seems to say only > >one locationErrorValue per inserter, and the second seems to suggest > >that you can have more than one. > > > >13. "It is allowed, but NOT RECOMMENDED, for more than one > SIP element > >to > > insert location into a request along its path." > >and later: > >"However, if location is already in a SIP request, a SIP server > > SHOULD NOT add another LbyR that identifies the same > target in the > > PIDF-LO (in the <tuple-id> element) to the same request." > >Isn't one of these statements redundant? > > yep > > >In fact the first statement is > >broader than the second statement, so I guess the second statement is > >redundant. In other words, if it is not recommended that > more than one > >SIP element can insert location, then it follows that a second SIP > >element should not add a second location identifying the same target. > > correct > > > >14. "However, if > > the Geolocation header parameter "routing-allowed" is present and > > set to "no", or is not present (knowing the default > behavior is "no" > > if not present, with or without a Geolocation header), > SIP servers > > MUST NOT view the contents of the LbyV message body." > >Anything that receives a request is a SIP server, including a UAS. I > >think "proxies" is intended here, or perhaps B2BUAs too. This is only > >one example of "SIP server" or "SIP servers" throughout the document, > >all of which need checking to see whether they are really intended to > >include UASs. > > yes, if any location recipient intermediary wants to view a location, > it *must* first look to see *if* it has permission to do so, and that > permission is in the "routing-allowed" header parameter. Is this not > clear? Does it need to be reworded to get this meaning across? [JRE] This is the section on proxy behaviour. A UAS implementer will not necessarily look at this section, so we should not make normative statements about UAS in this section. The term "SIP servers" includes UASs, and therefore I have a problem with it. > > > >15. It is not clear to me that "MUST NOT view" is a testable > >requirement. "MUST NOT route on" would be more appropriate. > > Geopriv wants this to mean "MUST NOT view" fully knowing their are no > IETF police. The aim is to prevent viewing and then the potential > for storing and sending to a non-signaling path 3rd party would be > prevented (if the intermediary obeyed this spec). > > Perhaps this is testable by demonstrating that if > "routing-allowed=no", that the message's location is immediately > removed from the intermediary's cache...? [JRE] I find this rather obscure, but I won't press the point if everyone else is happy. > > > >16. "No type of SIP server can delete a "Routing-allowed" header > > parameter," > >Should this be a MUST NOT statement? > > fair point, I'll change the text > > > >17. "but if one is not yet present, any SIP server MAY add a > > "Routing-allowed" header parameter with the value set to > "no" only." > >This seems a rather pointless thing to do. > > the intent from the Geopriv ID is to mandate the default behavior at > each intermediary (that follows this spec) to consider the policy > imposed by the originator of the request to be "no" unless the flag > is set to yes. > > >Why can't it be set to "yes" > >if there was no location there previously (and therefore upstream > >entities had not already used location for routing)? > > This indication is meant to dissuade any location inserted by any > intermediary (meaning the UAC did not insert location in the first > place) from using its own policy to inform downstream entities of the > UAC's location. In other words, this text is meant to allow a UAC to > tell everyone downstream that "I don't want my location used for > routing, even if I did not include my location in this request - but > someone else did". > > Does this make sense? > > Does the text need to be changed to reflect this meaning (if the > existing text doesn't make this clear)? [JRE] I can live with it as it is. > > > >18. "If there are any errors during dereferencing, or in > > the PIDF-LO itself, the proxy will error the original > request to the > > UAC with a locationErrorValue indicating what the proxy concluded > > was wrong with the location." > >What does "will error" mean here? Does it mean return a 4xx/5xx/6xx > >response code > > a 424 only, but with a LocationErrorValue that's in section 4.3 of > the existing version. > > >, or does it mean wait for a downstream entity to return a > >response code and insert a Geolocation-Error? > > no, it does not mean this. [JRE] So make it clear what is meant, rather than just saying "will error". > > > >Nits > >19. "The cid-url is defined in [RFC2392] to locate message body > > parts. This URI type MUST be present in a SIP request > if location > > is transmitted LbyV only." > >I think "only" should be deleted. > > fair > > > >20. In 4.3.5 on the subject of error 500: > >"Action(s) to be taken by Geolocation-Error receiver to a 1XX:" > >Change 1XX to 5XX. > > good catch, thanks > > > >21. In the example in 5.1: > >"Contact: <sips:[EMAIL PROTECTED]>" > >This is Alice's AOR (identical to what is in From) - it should be > >different, i.e., a contact URI. > > thanks, I'll change it > > > >22. "understanding > > that there are no IETF police" > >Is this really an appropriate statement for an RFC? Delete. > > <mumble> .... but I want to make a point here that this is > what's going on.... > > Do you have an alternate text suggestion that conveys this meaning, > but isn't so blatant? [JRE] Well, there are no IETF police to ensure that a proxy conforms to proxy requirements, and no IETF police to ensure that a UA conforms to UA requirements, but we don't bother to remind the reader. So why remind the reader in this case? I would prefer just to delete the phrase. John _______________________________________________ Sip mailing list https://www.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
