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