Apologies that these comments are rather late:
Technical comments:
1. Why do we permit Geolocation in a PRACK request? 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? 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. 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. Moreover, if both the UAC and the proxy
insert a location with the same inserted-by, they would not be able to
distinguish which error code relates to the location they inserted. 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), or if it doesn't have one, its IP
address? 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. Have there been any discussions on this? It might
require more than just fixing the example - it might require more text
on UAC behaviour to address this issue.
There are other instances in the document of inappropriate inserted-by
values.
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.
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.
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. 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.
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.
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.
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. 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".
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.
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. 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? 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.
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.
15. It is not clear to me that "MUST NOT view" is a testable
requirement. "MUST NOT route on" would be more appropriate.
16. "No type of SIP server can delete a "Routing-allowed" header
parameter,"
Should this be a MUST NOT statement?
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. 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)?
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, or does it mean wait for a downstream entity to return a
response code and insert a Geolocation-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.
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.
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.
22. "understanding
that there are no IETF police"
Is this really an appropriate statement for an RFC? Delete.
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
