Comments on: draft-ietf-sip-location-conveyance-07
Detailed review comments received from at least:
Note Henning also sent a marked up copy to the authors – not directly reproduced here.
No. |
Location |
Comment type |
Commentor |
Comment |
Resolution |
1 |
General |
Technical |
Hannes
Tschofenig |
I actually have two
questions in this context: * Shouldn't the
"SIP Location Conveyance" document define this term and use it in
it's document? * Is it actually true
that the LS will always have an LG attached to it? Typically, the LS will
just talk to some network technology specific LGs anyway. Now, I would define the
LIS as: " Location Information
Server (LIS): A LIS is a Location
Server located in the Access Provider's domain that is either co-located with
a Location Generator (LG) or has access to one or multiple LGs. The terms
"Location Server", "Access Provider" and "Location
Generator" are taken from RFC 3693. " |
James Polk: with my
Conveyance author hat off = nooooo...! Why would this (a LIS)
be defined in a SIP spec (that talks about SIP user agents and SIP servers)? A LIS (if this exists
as "an entity") would be a SIP UA - and not a SIP server - and that
is covered in the Conveyance doc by talking about SIP UAs. |
2 |
General |
Technical |
Shida
Schubert |
1. Dealing with
multiple location information. As geolocation can be populated with
various location information some provided by UA, some provided by
intermediaries, it may be useful for there to be an ability where UA
can express preference among location information it provides. Currently the spec doesn't say anything
about how UAS/server selects the location to be parsed when there are
multiple location information. Related to this, section with UAS behavior
should elaborate on when 424 is to be returned. Is it when one of
the many location information was problematic? Or is it when all of which
UAS tried failed? Obviously there will be variation but some guidelines
may be helpful. Also, desirable behavior of UAS/proxy
handling message with multiple location information may be desirable. Now if we don't want to deal with multiple
location information, it may be better to change the relevant
text from MAY to NOT RECOMMENDED. |
|
3 |
General |
Technical |
Henning
Schulzrinne |
-
The use of multiple location values is under-defined. There are some clear
cases where this is useful or potentially useful, and others where it isn't.
The reader is only left with some vague warnings that this could be
"confusing". That is rather confusing. |
|
4 |
General |
Technical |
Rishu
Jain |
2)
Location by reference overhead: |
|
5 |
General |
Technical |
Rishu
Jain |
3)
"retransmission-allowed" |
|
6 |
General |
Technical |
Rishu
Jain |
4)
What is the behavior in following case: |
|
7 |
General |
Technical |
Rishu
Jain |
7)
<sips: username@server.com> or <sips:server.com/username> |
|
8 |
General |
Technical |
Rishu
Jain |
8)
Why only PIDF format is selected. |
|
9 |
General |
Technical |
Rishu
Jain |
9)
Assume the case that UAC has sent his identity in the first INVITE. |
|
10 |
General |
Technical |
Shida
Schubert |
3. General problem with
debugging the warning code and 424 response. > Because the location URI can be added by
proxy, when warning code is sent, it would be useful to include the location URI (cid, sips, pres etc.) that
triggered the error/warning. This would allow UA to see if location was
added by intermediary, which location was malformed etc. |
|
11 |
General |
Editorial,
major |
Martin
Thomson |
Editorial, Major: *:
I'd like to see the new 'routing-query-allowed' defined in schema and
in one of the examples (preferably the unencrypted one, since the proxy is
unlikely to be able to see the encrypted LO).
(Incidentally, is this parameter an extension, or is the intent to
update RFC 4119?) |
|
12 |
General |
Editorial |
Henning
Schulzrinne |
- The
authors should avoid the passive voice and convoluted sentence constructions
that comprise whole paragraphs; they make the document rather tedious to
read. Often, antecedents of pronouns are unclear. |
|
13 |
General |
Editorial |
Henning
Schulzrinne |
- The text
is repetitive, but differs in subtle nuances upon repetition, so it is
unclear what is normative behavior. |
|
14 |
General |
Editorial |
Henning
Schulzrinne |
- A colon
cannot appear in the middle of a sentence. |
|
15 |
General |
Editorial |
Henning
Schulzrinne |
-
Throughout, it should be "header field", not "header". |
|
16 |
General |
Editorial |
Henning
Schulzrinne |
- There
are lots of unexplained uses of MAY vs. may. MAY is used for some future
actions of standards-writers instead of implementors. |
|
17 |
General |
Editorial |
Henning
Schulzrinne |
- In
several instances, SHOULD or SHOULD NOT is used without any guidance as to
when the stated rule can be violated or what bad thing would happen if the
rule is violated. |
|
18 |
General |
Editorial |
Henning
Schulzrinne |
- It is
unclear whether "routing" refers to "retargeting" or
something else. |
|
19 |
General |
Editorial |
Henning
Schulzrinne |
- The use
of by-value and by-reference is confusing. All elements in the header field
are by reference, as they refer to a location elsewhere, even if in the same
message. Where cid: is meant and where this requires special SIP element
behavior, it should simply be called out as such. (For example, if a data URL
were to be used later, it would be clearly "by value" and maybe the
only true by-value, but much of the by-value discussion doesn't apply.) |
|
20 |
General |
Editorial |
Henning
Schulzrinne |
- The
document should, after first use, stick to UA (or UAC and UAS, as
appropriate). It alternates randomly between spelling it out or using the
abbreviation. |
|
21 |
General |
Technical |
Henning
Schulzrinne |
- As a
side note, I was roundly denounced as being out of touch with reality when I
called for the use of multi-part MIME in another context in Prague (SDP
capability negotiation), since everybody except me knew that nobody
implements multi-part. Similarly, S/MIME seems to be essentially
unimplemented, judging from the SIPit reports. Should we be honest enough to
say that this means that really only L-by-R will be supported in practice? |
|
22 |
General |
Technical |
Richard
Barnes |
1. The draft says
several times that proxies cannot insert LbyV because they can't modify
bodies. That seems like a small reason
to remove a potentially important use case, and it seems to contradict the
fact that the ABNF in section 3.2 allows for the use of "data:"
URIs. |
|
23 |
General |
Technical |
Richard
Barnes |
2. More generally, the
looseness of the criteria for allowable URIs could also allow for URIs that
convey LI outside of a PIDF-LO, either by reference or by value (e.g., the
"geo:" URI defined in draft-mayrhofer-geo-uri). Perhaps this could be restricted to the
usage "sip:", "sips:", and "pres:" defined by
this document, plus any specific LbyR protocols later defined. |
|
24 |
General |
Technical |
Richard
Barnes |
3. Likewise, I don't
see anything that says that the body part indicated by a "cid:" URI
or returned by a reference MUST be a PIDF-LO (although this is said
throughout). |
|
25 |
General |
Technical |
Richard
Barnes |
4. Several times, the
draft says that it's only describing a "push", but there are at
least two places it defines mechanisms for "pull": The inclusion of
the "geolocation" option tag in a Require header, and the
description of the usage of SIP as a dereferencing protocol. |
|
26 |
General |
Technical |
Richard
Barnes |
5. The
routing-query-allowed element for PIDF-LO is never defined. This definition would be a better place for
a lot of the discussion in section 5.3 (just in the introduction, not
subordinate bullets). |
|
27 |
General |
Technical |
Richard
Barnes |
6. Several times, the
document assumes that content protected with S/MIME is encrypted, when it
could be signed, but otherwise readable. In most cases where use
of S/MIME for encryption causes problems, use of S/MIME for signing only
doesn't, and these cases should be noted. |
|
28 |
General |
Technical |
Richard
Barnes |
7. Several sections
start out by talking about how sensitive location information is. This repetition should be removed. |
|
29 |
General |
Technical |
Keith
Drage |
- General: usage of Geolocation and
location bodies in responses. Obviously errors cannot be used in response to
this, and location based routeing at a proxy is inappropriate. If we are
allowing location in responses, we need to be clearer about which bit of the
procedures apply, and which do not. This should probably be specifically
worked in section 5. |
|
30 |
General |
Technical |
Keith
Drage |
- Dialog Usage of new 424? RFC 4485 (http://www.ietf.org/rfc/rfc4485.txt)
section 5 specifies: Dialog Usages: SIP allows for requests
that normally create their own dialog (such as SUBSCRIBE) to be used
within a dialog created by another method (such as INVITE). In such a case, there are said to be multiple usages of that
dialog. Extensions SHOULD consider their interaction with dialog
usages. In particular, extensions that define new error response codes
SHOULD describe whether that response code causes the dialog and all
usages to terminate, or just a specific usage. |
|
31 |
Title |
Editorial |
Joszef
Varga |
Session Initiation Protocol Location Conveyance à Location
Conveyance for the Session Initiation Protocol (SIP) |
|
32 |
1 |
Editorial |
Joszef
Varga |
1st
paragraph This document describes how Location can
be "conveyed" (that is, sent on the Internet) from a SIP user
agent, or in some circumstances a proxy server acting on
behalf of a user agent, to another entity using the SIP [RFC3261]
protocol. Here "Location" is a description of the physical geographical
area where a User Agent currently exists. This document uses the term
"conveyance" to describe scenarios in which a SIP user
agent client (UAC) is telling or informing a user agent server (UAS)
where the UAC is. This is different from a UAC asking or seeking the
location of where the UAS is.
Conveyance is a push model, where seeking is a pull model, and therefore not discussed here. -
should "conveyance" be "location
conveyance" -
delete "telling or" |
|
33 |
1 |
NIT |
Shida
Schubert |
1.
Section 1, 1nd paragraph, 3rd sentence. > The recipient of the location is not UAS alone
as noted in the 2nd paragraph of this section, so you may want
to say server or UAS & proxy rather than UAS alone. |
|
34 |
1 |
Technical |
Umesh
Sharma |
>1. Introduction > >> It
defines a "target" as the entity whose location is being >transmitted, in
this case, it is > >>the user
agent's (UA) location. >Target is probably
only the "User Agent(UA)" (or the physical box in >which UA is
present). I reworded the first
part of the second paragraph to: "Geographic
location in the IETF is discussed in RFC 3693 (Geopriv Requirements)
[RFC3693]. It defines a "target" as the entity whose location is
being sought. In this case, this is the user agent's (UA) location. " --- US: I am afraid it still
seems to mean the same. This-->target-->UA's
location I mean
This-->target-->UA UA's Location would be
represented as PID-LO. Otherwise in the
reworded para: If you say something
like "In this case, this is the user agent whose location is
desired" etc. then UA becomes the entity. --- |
|
35 |
1 |
Editorial |
Joszef
Varga |
2nd
paragraph Geographic location in the IETF is
discussed in RFC 3693 (Geopriv Requirements) [RFC3693]. It defines a "target" as the
entity whose location is being transmitted, in this
case, it is the user agent's (UA) location. A [RFC3693] "using protocol"
defines how a "location server" transmits a "location
object" to a "location recipient" while maintaining the contained privacy
intentions of the target intact. This document describes the
extension to SIP for how it complies with the using protocol
requirements, where the location server is a User Agent or Proxy Server and
the location recipient is another User Agent or Proxy Server. -
Capitalisation consistent with 3693, 4119, e.g.
"Target" (throughout document) -
Capitalisation of User Agent and use of abbreviation – do
search replace throughout document -
LS can be the UA (by-value case) or a separate entity
(by-reference) see the figure 1 in the requirement doc |
|
36 |
1 |
NIT |
Shida
Schubert |
2. Section
1, 3rd paragraph, 2nd sentence. > I think you mean "target" where the
text says thing. OLD: A PIDF-LO is an XML Schema specifically for
carrying geographic location of a thing. NEW: A PIDF-LO is an XML Schema specifically for
carrying geographic location of a target. |
|
37 |
1 |
Editorial |
Joszef
Varga |
(3rd para) Location can be transmitted by-value or
by-reference. The "value" in this SIP extension is in the form of a
Presence Information Data Format - Location Object, or PIDF-LO, as
described in [RFC4119]. A PIDF-LO is an XML Schema specifically for
carrying geographic location of a thing. Location-by-value refers to a user agent including a PIDF-LO as a body part of a
SIP message, sending that location object to another SIP
element. Location-by-reference refers to a user agent or proxy server
including a URI in a SIP message which can be exchanged by a
location recipient for a location object, in the form of a PIDF-LO. - Aganst final location recipient:
What about Proxy Server? Location based routing in case location-by-reference
used (e.g. e-call) |
|
38 |
1 |
Editorial |
Joszef
Varga |
(4th para) As recited in RFC 3693, location often
must be kept private. The location object (PIDF-LO) contains rules
which are binding on the location recipient and controls onward
distribution and retention of the location. This document describes the security and
privacy considerations that must be applied to
location conveyed with SIP. - "location" OK without
caps, I think the introduction of the term"Location" at the
beginning is unnecessary |
|
39 |
1 |
Technical |
Umesh
Sharma |
5th para. > >> ... SIP
request, where the choice of the next hop (and usually, the > >> outgoing
Request URI) is determined by the location of the UAC > >> which is
in the message by-value or by-reference > >May consider
rewording like >"... is
determined by the location of the UAC which may be conveyed in >the message." >or ".. is
determined by the location of the UAC which may be present as >by-vlaue or
by-reference." >etc. Here, I am reading that
you want the text to change from a case in which location is in the message,
to one in which location *may* be in the message. While I agree completely
that location can only be a MAY in general, for location based routing (the
subject of this part of the text, we should indicate that location is present
in order to perform this location based routing. Do you agree? --- US: agreed here(MAY part). Additionally, I wanted
the sentence to be re-formatted for a better placing of the "by-value or
by-reference" part, but that is non-issue. ---- |
|
40 |
1 |
Editorial |
Joszef
Varga |
(5th para) Often, location is sent from the User
Agent Client to the User Agent Server, or vice versa for purposes that
are beyond the scope of this document.
Another use for location is location-based routing of a SIP request, where the choice of the next
hop (and usually, the outgoing Request URI) is determined by the
location of the UAC which is in the message by-value or
by-reference. This document describes how location may be conveyed from the UAC,
or a proxy acting on its behalf, to a routing proxy. How the location is actually used to determine the next hop or Request-URI is
beyond the scope of this document. -
Delete " Often, location is sent from the User Agent
Client to the User Agent Server, or vice versa for purposes that are beyond
the scope of this document"? -
In relation to "SIP" is it protocol independent
general text. |
|
41 |
1 |
Editorial |
Keith
Drage |
- 1, 5th para: Often, location is sent from the User
Agent Client to the User Agent Server, or vice versa for purposes that
are beyond the scope of this document.
Another use for location is location-based routing of a SIP request, where the choice of the next
hop (and usually, the outgoing Request URI) is determined by the
location of the UAC which is in the message by-value or
by-reference. This document describes how location may be conveyed from the UAC,
or a proxy acting on its behalf, to a routing proxy. How the location is actually used to determine the next hop or Request-URI is
beyond the scope of this document. change "may" to "can". |
|
42 |
1 |
Editorial |
Richard
Barnes |
(6th para) Section 1, paragraph
starting "The Geolocation header is introduced..." This paragraph should
be broken into multiple sentences. |
|
43 |
1 |
Editorial |
Keith
Drae |
- 1, 6th para: The Geolocation header is introduced to
signify that location is included in a SIP message to provide
either a content identifier (cid:) pointer to the body part containing
the UA's PIDF-LO, or a location-by-reference URI that may
subsequently be "dereferenced" by a using protocol (which may be SIP or
another protocol). change "may" to "can". |
|
44 |
1 |
Editorial |
Joszef
Varga |
(last para) Capitalise
"SIP" |
|
45 |
1 |
Editorial |
Keith
Drage |
- 1, last para: In
this document, we frequently refer to the "emergency case". This refers to a specific, important use of sip
location conveyance where the location of the caller is used to
determine which Public Safety Answering Point (PSAP) should receive an
emergency call request for help (e.g. a call to 1-1-2 or 9-1-1). This is an example of location-based routing. The location conveyed is also used by the PSAP to dispatch first responders to the
caller's location. There are special security considerations which
make the emergency case unique, compared to a normal location
conveyance within SIP. change "should" to "is expected to"
to avoid RFC 2119 type language here. |
|
46 |
2 |
Editorial |
Joszef
Varga |
"MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" I guess these should be
always all caps |
|
47 |
3.1 |
NIT |
Shida
Schubert |
3. Section 3.1
paragraph 1, 2nd sentence > Missing a closing bracket. OLD: The Geolocation header contains either a
URI which may be a "cid:" URI (Content Identification, per [RFC2392] NEW: The Geolocation header contains either a
URI which may be a "cid:" URI (Content Identification, per [RFC2392]) |
|
48 |
3.1 |
Editorial |
Joszef
Varga |
This document creates a new SIP header:
Geolocation. The Geolocation header contains either a URI
which may be a "cid:" URI (Content Identification, per [RFC2392], or
a location-by-reference URI to be dereferenced by a location
recipient to retrieve the location of the UAC. -
"creates" à "defines" -
"header" à "header field" and
throughout document -
cid: Why not simply cid URI? As for
sip, sips, pres. -
UAC à Target UA |
|
49 |
3.1 |
Editorial |
Henning
Schulzrinne |
-
Unless the draft is trying to win the "longest URI parameter"
competition, something shorter such as "used-for-routing" would be
sufficient. |
|
50 |
3.1 |
Technical |
Umesh
Sharma |
>3.1 > > >> Since
body parts may not be inserted by a proxy server, >location-by-value > >> cannot be
inserted by a proxy. >A UA's proxy or
server would like to insert it by-value, where a >particular Location
Server may not be globally accessible ? Here, I am not sure I
understand your question. RFC 3261
does not allow SIP Proxies from inserting message bodies, so even if the
proxy knows where the UAC is, it cannot insert this location information
by-value. The terminology
"Location Server" in Geopriv is the IP entity that builds the
PIDF-LO and is first to transmit it.
Since proxies cannot insert location by-value, proxies cannot be
Location Servers. UACs can be location servers, and B2BUAs can be location
servers. ---- US: That would be the
Location Generators (entities that build PIDF-LO), Location Servers would
receive these PIDF-LO from the LGs (RFC3693) and/or receive subscriptions
from LRs. ---- Within all this, you
mention the location server "may not be globally accessible". This
tells me you are actually referring to the server where the
location-by-reference URI points to (i.e. where the UAC's PIDF-LO is -
waiting to be accessed - which is called dereferencing). This is not a
"Location Server" in Geopriv, and RFC 3693 defines this. ----- US: But here I think
this(the server) would correspond to an entity like Presence Agent that would
respond to dereferencing SUBSCRIBE requests with NOTIFY's but this is one of
the function of a Location Server [RFC2693]. ---- This document already
states the dereference server needs to be accessible if location is conveyed
by-reference, otherwise location is not conveyed (which is the point of this
extension). ---- Ok ----- |
|
51 |
3.1 |
Editorial |
Richard
Barnes |
(1st para) Section 3.1, paragraph
starting "This document creates..." Missing closing
parenthesis after "[RFC2392]". |
|
52 |
3.1 |
Editorial |
Keith
Drage |
- 3.1, 1st para: This document creates a new SIP header:
Geolocation. The Geolocation header contains either a URI
which may be a "cid:" URI (Content Identification, per [RFC2392], or
a location-by-reference URI to be dereferenced by a location
recipient to retrieve the location of the UAC. Change "may" to "can". |
|
53 |
3.1 |
Editorial |
Joszef
Varga |
(3rd para) If the URI in the Geolocation header is a
scheme other than "cid:", another protocol operation is needed by
the message recipient to obtain the location of the target
(UA). This is location-by-reference. This document
describes how a SIP presence subscription [RFC3856] can be used as a
dereference protocol. -
1st sentence à " If the Geolocation header
field value is a in the URI scheme other than "cid:"," -
"message" à "SIP message" |
|
54 |
3.1 |
Editorial |
Josezef
Varga |
(4th para) The Geolocation header, either with the
PIDF-LO in a body or as a location-by-reference URI, may be included
by a User Agent in a message.
A proxy server may assert location of the UA by inserting the header, which must specify a
location-by-reference URI. Since body parts may not be inserted by a proxy
server, location-by-value cannot be inserted by a proxy. -
message à SIP message -
proxy à Proxy Server |
|
55 |
3.1 |
Editorial |
Keith
Drage |
- 3.1, 4th para: The Geolocation header, either with the
PIDF-LO in a body or as a location-by-reference URI, may be included
by a User Agent in a message.
A proxy server may assert location of the UA by inserting the header, which must specify a
location-by-reference URI. Since body parts may not be inserted by a proxy
server, location-by-value cannot be inserted by a proxy. Change "may" to "can". |
|
56 |
3.1 |
Technical |
Umesh
Sharma |
5th para > >> The
"inserted-by" parameter has values of "endpoint" or
"server", > >>
indicative of which entry ... >indicative of which
entity are you taking issue
with the word "indicative"? If so, how about me changing this to
"... indicating which entity..." ---------- US: ok:
"...indicating which entity added location to the message." ------------ |
|
57 |
3.1 |
Editorial |
Keith
Drage |
- 3.1, 5th para: The Geolocation header may have parameters
that are associated with a URI in the header. The "inserted-by" parameter has
values of "endpoint" or
"server", indicative of which entry added location to the message. This header parameter MAY be
added every time a new location is added into a message. Change first "may" to "can". For
the final sentence, I would prefer this appeared elsewhere in the document as
I would like to keep RFC 2119 language out of a section entitied
"overview". |
|
58 |
3.1 |
Technical |
Umesh
Sharma |
> >>If a SIP
message is routed within the network based on the location > >>contained
within that message, the "message-routed-on-this-uri".. > >"within the
network" -- the scope of network is not clear. fair -- how about I
take "within the network" out of the sentence? --- ok. --- |
|
59 |
3.1 |
Technical |
Richard
Barnes |
Section 3.1, paragraph
starting "If a SIP message is routed..." The requirement that
header parameters SHOULD NOT be deleted seems like it should be a MUST
NOT. What's the case where a parameter
SHOULD be deleted? |
|
60 |
3.1 |
Editorial |
Joszef
Varga |
(6th
para) If a SIP message is routed within the
network based on the location contained within that message, the
"message-routed-on-this-uri" parameter MUST be added as a header
parameter of the URI used to route the message. Once a header parameter is added to a Geolocation header, it SHOULD NOT be
deleted in transit to the ultimate destination. -
"contained" à "contained or
referenced". -
Add " in the Geolocation header field" to "
header parameter of the URI" -
with ref to "SHOULD NOT be deleted" What happens
if afterwards a proxy has location info, adds another Geolocation header, and
routes based on that? |
|
61 |
3.1 |
Editorial |
Joszef
Varga |
8th
para This document describes an extension to
PIDF-LO, the "routing-query-allowed" element,
defined in the 'usage-rules' element. When set, this allows an element
receiving location to transmit the location to another element
to obtain routing information. When used in conjunction with the "retransmission-allowed"
element, the rule maker can control distribution of the location information
for location-based routing. - "routing-query-allowed"
element: Add to IANA registration |
|
62 |
3.2 |
Technical |
Rishu
Jain |
6)
Section 3.2: Use of the header in BYE, INFO and REFER |
|
63 |
3.2 |
NIT |
Shida
Schubert |
4. Section 3.2,
paragraph 1, 1st sentence > It reads like the spec creates a new
IANA registry.. IANA consideration covers all of which has to do with IANA,
so I think all you have to say here is that the spec defines a new SIP
header: Geolocation. |
|
64 |
3.2 |
NIT |
Shida
Schubert |
5. Section 3.2,
paragraph 1, 2nd sentence > The Geolocation heade MUST contain one
of two types of URIs is misleading I believe what you want to say is "at
least one of two types of URIs" OLD: The Geolocation header contains either a
URI which may be a "cid:" URI (Content Identification, per [RFC2392] NEW: The Geolocation header contains either a
URI which may be a "cid:" URI (Content Identification, per [RFC2392] |
|
65 |
3.2 |
Editorial |
Joszef
Varga |
(3rd para) A location-by-value content-ID (cid-url)
[RFC2392] indicates which message body part contains location for
this UA. - URL? |
|
66 |
3.2 |
Technical |
Richard
Barnes |
Section 3.2, paragraph
with ABNF Since the Geolocation
header can hold multiple values, should messages be forbidden to have
multiple Geolocation headers? Also, this
specification is very permissive about what URIs may be inserted. Perhaps it should be restricted to SIP,
SIPS, PRES, and CID for now, with a
provision for adding more in the future. |
|
67 |
3.2 |
Technical |
Richard
Barnes |
Section 3.2, paragraph starting
"The cid-url is defined..." The meaning of the
sentence "This URI MUST be present if location is by-value in a
message" needs to be re-worded or deleted. As I read it, it would imply that if
a message has a PIDF-LO body part (for any reason), and a
Geolocation header, than that header must have a CID URI pointing to that body
part. |
|
68 |
3.2 |
NIT |
Shida
Schubert |
6. Section3.2,
paragraph before the table, last sentence. > "is" is missing. OLD: Discussing location using the PUBLISH Request Method out of scope for this
document. NEW: Discussing location using the PUBLISH Request Method is out of scope for this
document. |
|
69 |
3.2 |
Technical |
Richard
Barnes |
Section 3.2, paragraph
starting "Use of the header..." Use of the header in
BYE is stated to be both allowed and undefined. |
|
70 |
3.2 |
Technical |
Umesh
Sharma |
>3.2 > >>contain one of two types of
URIs:contain of the two types of URIs. > >>Discussing
location using the PUBLISH Request Method out of scope > >>for >this document >]is[ out of scope
for this document thanks, changed |
|
71 |
3.2 |
NIT |
Shida
Schubert |
7. Section 3.2, 2nd
last paragraph, 2nd sentence. > Confusing, needs to clarify that
proxy is not allowed to modify the pre-existing URI values and
associated parameters. OLD: A proxy MAY add the Geolocation header,
but MUST NOT modify the contents of an existing
Geolocation header. NEW: A proxy MAY add the Geolocation header,
but MUST NOT modify any pre-existing URI values
and its associated parameters of an existing Geolocation header. |
|
72 |
3.2 |
NIT |
Shida
Schubert |
8. Section 3.2, 2nd
last paragraph, last sentence. > location-by-reference URI not
location-by-reference. OLD: Therefore, a Geolocation header added by
a proxy MUST specify location-by-reference. NEW: Therefore, a Geolocation header added by
a proxy MUST specify location-by-reference URI. |
|
73 |
3.2 |
Technical |
Henning
Schulzrinne |
- INFO and REFER are
excluded. Why? (For example, INFO might be a good candidate for mid-call
location updates; clearly, UPDATE is not unless you are also changing the
session description.) |
|
74 |
3.2 |
Technical |
Henning
Schulzrinne |
- PUBLISH is excluded
with some ominous-sounding warnings that have the flavor of "unspeakable
horrors will happen to your children and grand children, but we dare not
speak their name". Why not simply say that you could simply PUBLISH
PIDF-LO as a described in the presence-for-location-info RFC? |
|
75 |
3.2 |
Technical |
Richard
Barnes |
Section 3.2, paragraph
starting "The Geolocation header MAY be..." A Geolocation header
added by a proxy could specify LbyV, e.g., if it contained a
"data:" URI. |
|
76 |
3.3 |
Editorial |
Richard
Barnes |
Section 3.3, paragraph
starting "The UAC can use whatever means..." Need an article before
"SIP Intermediary". |
|
77 |
3.4 |
NIT |
Martin
Thomson |
Editorial, Minor: 3.4 & 9.4: Warnings refer to unsupported
"schema". This should be
"scheme" [RFC3986]. |
|
78 |
3.4 |
Technical |
Henning
Schulzrinne |
- The Warning header
has no way to indicate which of several locations it refers to, thus making
it useless in the common case that you have both a protected (high-res)
location in the body and an unprotected non-cid reference. (See Marc's recent
proposals for an example.) At best, one can guess by circumstances. |
|
79 |
3.4 |
Technical |
Henning
Schulzrinne |
- It is unclear whether
the Warnings can appear only in a 424. |
|
80 |
3.4 |
Technical |
Henning
Schulzrinne |
(see also comment
against 3.4.7 to put this in context) This, in general,
illustrates that the plethora of Warnings is unlikely to be helpful. Almost
all the conditions need to be fixed by humans, rather than by machine, and
need significant extra information to be useful, presumably in some free-text
format, such as the 424 body. If that information needs to be provided
anyway, why bother with the hyper-specific warnings? After all, it's not
like the UAC software is going to be saying "hmm, I really didn't want
to include my cubicle number, but since the UAS insists, I guess I'll be nice
and include it this time. But, hey, maybe the UAS is happy with the floor
number?". |
|
81 |
3.4 |
Editorial |
Keith
Drage |
- 3.4, 3rd para: The Warning header allows for multiple
warning codes be returned in the same response. If a location-by-reference is sent and the supplied scheme is not desired or cannot
be processed, but more than one other scheme can be, the 424 response
can list more than one code from the 720-724 range in the
response. The UAC may subsequently retry the operation with one
of the schemes supported or desired by the recipient. Change "may" to "can". |
|
82 |
3.4 |
Editorial |
Richard
Barnes |
(4th para) Section 3.4, paragraph
starting "To illustrate this..." Replace "would be
in here" with "is" |
|
83 |
3.4.1 |
Technical |
Richard
Barnes |
Section 3.4.1, paragraph
starting "A Warning header ..." You refer to data-URLs
here; it would be useful to have an Informative reference to RFC 2397. |
|
84 |
3.4.1 |
Editorial |
Henning
Shulzrinne |
- The 701 code should
indicate which other warnings are subsumed by it. What value does it add
compared to not including it? |
|
85 |
3.4.1 |
Technical |
Joszef
Varga |
(1st para) A Warning header with the code 701
"Location Format not supported" means the location format supplied in the
request, by-value or by-reference, was not supported. This cause means the recipient understood that location was included in
the message, but the format is not supported. Perhaps the format was a freeform text
format or data-URL and the recipient only understood
location in RFC 4119 PIDF-LO format (civic or coordinate). If a
more specific Warning code is available, it MUST be used. For example, if the format is understood, but not desired, a 702 or 703
Warning header should be returned in a 424 response, depending on
which location format is desired. The same applies to a location
recipient that only understands one format and did not receive
that format. For example, if a message containing coordinate
formatted location arrives but the recipient only can process civic
formatted location, a 703 Warning header should be returned in a 424
response. -
Query as to whether really needed -
should be à "SHOULD be" |
|
86 |
3.4.1 |
Editorial |
Keith
Drage |
- 3.4.1, 1st para: A Warning header with the code 701
"Location Format not supported" means the location format supplied in the
request, by-value or by-reference, was not supported. This cause means the recipient understood that location was included in
the message, but the format is not supported. Perhaps the format was a freeform text
format or data-URL and the recipient only understood
location in RFC 4119 PIDF-LO format (civic or coordinate). If a
more specific Warning code is available, it MUST be used. For example, if the format is understood, but not desired, a 702 or 703
Warning header should be returned in a 424 response, depending on
which location format is desired. The same applies to a location
recipient that only understands one format and did not receive
that format. For example, if a message containing coordinate
formatted location arrives but the recipient only can process civic
formatted location, a 703 Warning header should be returned in a 424
response. Query RFC 2119 language on use of word "should".
Is it or isn't it. If it is not, change the wording to make clearer this is
part of the example. If it is not, then make clear that it is a normative
requirement by deleting "For example". |
|
87 |
3.4.1 |
Editorial |
Joszef
Varga |
(2nd para) Recommended warn-text: Location format not
supported - f or F |
|
88 |
3.4.1 |
Editorial |
Keith
Drage |
- 3.4.1, 4th para: A proxy server may assert location of the
UA by inserting the header, which must specify a
location-by-reference URI. Since body parts may not be inserted by a proxy
server, location-by-value cannot be inserted by a proxy. "must" or "MUST". If the
requirements are elsewhere use a different word to "must". change "may not" to "cannot". |
|
89 |
3.4.2 |
Editorial |
Joszef
Varga |
(Title) Delete "Instead" |
|
90 |
3.4.3 |
Editorial |
Joszef
Varga |
(Title) Delete
"Instead" |
|
91 |
3.4.5 |
NIT |
Shida
Schubert |
9. Section 3.4.5 > I believe this warning code is
appropriate when PIDF fetched via SUB/NOT doesn't contain the LO portion. |
|
92 |
3.4.5 |
Technical |
Henning
Schulzrinne |
- I don't know that the
difference is between not being able to locate a URL and not finding the
corresponding cid. |
|
93 |
3.4.5 |
Editorial |
Keith
Drage |
- 3.4.5, 1st para: A Warning header with the code 705
"Cannot find location" means location should have been in the message
received, but the recipient cannot find it, either because it is not
in the message, or it is encrypted/opaque to the recipient. "should have been" --> "was
expected". |
|
94 |
3.4.6 |
Technical |
Richard
Barnes |
Security / Privacy
Concerns: 6. The draft's stance
on multiple locations seems to take an absolutist stance on multiple
locations. In particular, Section
3.4.6 allows for multiple locations to cause a call to fail (which seems
dangerous to me). This seems dangerous
in an emergency context. |
|
95 |
3.4.6 |
Technical |
Shida
Schubert |
2. Section 3.4.6
Warning code 706 Conflicting Locations Supplied > I understand its use, but considering
proxy may add Geolocation header with reference URI, it's out of
UA's control to restrict the number of location to be conveyed
unless... 1. UA can tell the proxy not to add
location 2. UA can find out if location was added
by other entity in which case it can omit adding location
itself and have the proxy add location or route a call through other
proxy which may not add location. |
|
96 |
3.4.6 |
Technical |
Richard
Barnes |
Section 3.4.6 Allowing this response
code would seem to encourage UASs to reject calls with multiple
locations. This is obviously dangerous
in an emergency setting. Also, it seems odd to include this in a 424
message that goes back to the UAC, since
there may not be anything he can do about it (e.g., if a proxy is
adding conflicting location information). |
|
97 |
3.4.6 |
Technical |
Joszef
Varga |
(2nd para) A typical reaction to receiving this
warning code is to reduce the number of different locations supplied in
the request, and send another message to the location recipient. - What happens if a proxy adds a
conflicting location every time? Any priority / processing rules at the UAS? |
|
98 |
3.4.6 |
Editorial |
Joszef
Varga |
(last para) Warning: 706 alice.example.com
"conflicting locations supplied" - Caps (on Warning name) |
|
99 |
3.4.7 |
Technical |
Henning
Schulzrinne |
- The 707 Warning
indicates that the location is "incomplete". The value of this is
unclear. Does it mean that the geo information has an insufficient number of
digits? Does the receiver want cubicle-level information? Should it add
digits until the warning disappears? Or does this refer to some syntactic
deficiency or a logical deficiency, such as a missing 'country' field in
PIDF-LO when a state is provided? |
|
100 |
3.4.7 |
Editorial |
Joszef
Varga |
(3rd para) Recommended warn-text: Conflicting
Locations Supplied - L or l? |
|
101 |
3.4.7 |
Editorial |
Joszef
Varga |
(5th para) Warning: 706 alice.example.com
"conflicting locations supplied" - L or l? |
|
102 |
3.4.12 |
Editorial |
Keith
Drage |
- 3.4.12: There are two sections
labelled such. |
|
103 |
3.4.12 |
Editorial |
Joszef
Varga |
(Title) 3.4.12 Warning code 720 Unsupported Schema - sip
desired - "sip" à "SIP" ? |
|
104 |
3.4.12 |
Technical,
minor |
Martin
Thomson |
Technical, Minor: 3.4.12:
Note that providing a reference of this nature (which would allow for
a dereference operation that does not use TLS) could constitute a potential
privacy leak. UAs should only respect
this request in an emergency. |
|
105 |
3.4.12 |
Technical |
Henning
Schulzrinne |
- The use
of a Warning header to indicate desired URL schemes is inappropriate and has
no precedent. If desired, an Accept-Geolocation header field would be more
useful. You don't want to extend the Warning list each time a URI scheme is
added. |
|
106 |
3.4.12 |
Editorial |
Joszef
Varga |
(3rd
para) Recommended warn-text: unsupported schema - Add "- SIP desired" |
|
107 |
3.4.12A |
Technical |
Henning
Schulzrinne |
- The use
of a Warning header to indicate desired URL schemes is inappropriate and has
no precedent. If desired, an Accept-Geolocation header field would be more
useful. You don't want to extend the Warning list each time a URI scheme is
added. |
|
108 |
3.4.12A |
Editorial |
Joszef
Varga |
(Title) 3.4.12
Warning code 721 Unsupported Schema - sips
desired - "sips"
à
"SIPS". |
|
109 |
3.4.12A |
Editorial |
Joszef
Varga |
(2nd
para) Recommended warn-text: unsupported schema - Add "SIPS desired" |
|
110 |
3.4.13 |
Technical |
Henning
Schulzrinne |
- The use
of a Warning header to indicate desired URL schemes is inappropriate and has
no precedent. If desired, an Accept-Geolocation header field would be more
useful. You don't want to extend the Warning list each time a URI scheme is
added. |
|
111 |
3.4.13 |
Editorial |
Joszef
Varga |
(2nd para) Recommended warn-text: unsupported schema - Add "pres desired" |
|
112 |
3.5 |
Technical |
Umesh
Sharma |
>3.5 > >> Appearance of the option tag in the Require
header is a request > >> for >location to > >> be conveyed. > From rfc3261 it is
inferred that the UAS needs to understand the >conveyance
information coming from UAC/etc. >Maybe an emergency
call where there are two PSAPs where call could be >forwarded, the one
who understands the Geo-LocationInfo ulitmately gets >the call. I think this is outside
the scope of this doc. This topic should be asked in ECRIT, as they have 2
docs defining the devices BCP and the Emergency calling Framework. Hopefully
there will be an emergency services network in front of the IP enabled PSAP
to route the call to a PSAP that can understand this extension. That said, I believe
what will happen is most (if not all?) IP based PSAPs understand this
extension from the beginning.
NENA and EMTEL are telling all
PSAPs in North America and the EU to do this. Several other areas of the
world are being told to do this also.
Of course we cannot be assured every IP enabled PSAP in the world
will, but it's likely to be based on something from the IETF, the ITU-T, 3GPP
or one of the other SDOs that attended last year's Emergency SDO conference
that agreed to this general mechanism to convey location to a PSAP from a SIP
phone. --- US: Ok, but is this contradicting the statement in
Section 5.2 which says "...A Require header with the geolocation option
tag indicates the UAC is requiring the UAS understand this extension or else
send an error response." as opposed to 3.5 "...Appearance of the option tag in
the Require header is a request for location to be conveyed." --- |
|
113 |
3.5 |
Technical |
Shida
Schubert |
5.
Section 3.5, 2nd paragraph, 2nd sentence. > Semantics of Require header with
"geolocation" option tag is unlear. > Section 3.5 reads as if it is to
request UAS to send back location but Section 5.2 merely implies that UAS
understands the specification. I believe there needs to be consistency
with the semantic. |
|
114 |
3.5 |
Technical |
Richard
Barnes |
(3rd Para) Section 3.5, paragraph
starting "A UAC SHOULD NOT include..." Need to define what the
semantic would be when included. Is it
requesting that a proxy
insert a Geolocation header? |
|
115 |
3.6 |
Technical |
Joszef
Varga |
New clause to define
the new value for the rule element? |
|
116 |
3.6 |
NIT |
Shida
Schubert |
10. Section 3.6, 1st
paragraph, 1st sentence. > I think what you are trying to say is
taht, when Geolocation header is used to include a location-by-reference
URI, sip, sips or pres URI SHOULD be used. Isnt' it? Right now, it reads
like when Geolocation header is set, URI with one of the scheme should be
set |
|
117 |
4 |
Editorial |
Henning
Schulzrinne |
- The term
"coordinates" is used to refer to geo-location, but not defined.
This term also seems at odds with usage elsewhere. GEOPRIV should agree on
one term for non-civic coordinates. |
|
118 |
4.1 |
Editorial |
Umesh
Sharma |
>4.1 >
>>...indicates the content-ID location [RFC2392] within the multipart > >> message body of were location information
is > >message body of
]where[ location information is Got it, thanks! |
|
119 |
4.1 |
Technical,
minor |
Martin
Thomson |
Technical, Minor: 4.1 & 4.2: The example PIDF-LO documents have a few
errors. Refer to
draft-ietf-geopriv-pdif-lo-profile.
Continued... |
|
120 |
4.1 |
Technical,
minor |
Martin
Thomson |
4.1 & 4.2: Remove
the xmlns:gs attribute, it isn't used. |
|
121 |
4.1 |
Technical,
minor |
Martin
Thomson |
4.1: This Point format
is deprecated (for a number of reasons).
Recommend the following form: <gp:location-info> <gml:Point
srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>33.001111
-96.68142</gml:pos> </gml:Point> </gp:location-info> |
|
122 |
4.1 |
Technical |
Martin
Thomson |
4.1 & 4.2: The
"method" and "provided-by" elements are in the wrong
context. An unfortunate consequence of
the structure of the RFC 4119 schema is that the "usage-rules" will
accept any old junk provided that it is in the "...:geopriv10"
namespace. Therefore, the given
documents validate, even if they aren't correct. Most likely those elements would be ignored
by some UASs. Place the method and provided-by elements
_after_ the usage-rules. |
|
123 |
4.1 |
Technical,
minor |
Martin
Thomson |
4.1 & 4.2: The
content model for the "provided-by" element does not permit
text. It only permits element
content.
<gp:provided-by>www.cisco.com</gp:provided-by> is not
valid. |
|
124 |
4.2 |
Editorial |
Henning
Schulzrinne |
- The second example
adds no value, just inflates the spec size. |
|
125 |
4.2 |
Technical,
minor |
Martin
Thomson |
Technical, Minor: 4.1 & 4.2: The example PIDF-LO documents have a few
errors. Refer to
draft-ietf-geopriv-pdif-lo-profile.
Continued... |
|
126 |
4.2 |
Technical,
minor |
Martin
Thomson |
4.1 & 4.2: Remove
the xmlns:gs attribute, it isn't used. |
|
127 |
4.2 |
Technical |
Martin
Thomson |
4.1 & 4.2: The
"method" and "provided-by" elements are in the wrong
context. An unfortunate consequence of
the structure of the RFC 4119 schema is that the "usage-rules" will
accept any old junk provided that it is in the "...:geopriv10"
namespace. Therefore, the given
documents validate, even if they aren't correct. Most likely those elements would be ignored
by some UASs. Place the method and provided-by elements
_after_ the usage-rules. |
|
128 |
4.2 |
Technical,
minor |
Martin
Thomson |
4.1 & 4.2: The
content model for the "provided-by" element does not permit
text. It only permits element
content. <gp:provided-by>www.cisco.com</gp:provided-by>
is not valid. |
|
129 |
4.2 |
Technical,
minor |
Martin
Thomson |
4.2: The
"civilAddress" element should be replaced by a
"civicAddress" (note the 'l' is replaced by 'c'). |
|
130 |
5 |
NIT |
Shida
Schubert |
11. SEction 5, 1st
paragraph, 3rd sentence. > term opposite UA sounds a bit odd. OLD: SIP endpoints SHOULD implement S/MIME to
encrypt the PIDF-LO message body (part) end-to-end
when the intended recipient is the opposite UA. NEW: SIP endpoints SHOULD implement S/MIME to
encrypt the PIDF-LO message body (part) end-to-end
when the intended recipient is another UA. |
|
131 |
5 |
NIT |
Shida
Schubert |
12. Section 5, 1st
paragraph, last sentence > Unclear whether the target of TLS is
the URI contained in the Geolocation header or the signalling path
which message holding the header is conveyed. |
|
132 |
5 |
Technical |
Richard
Barnes |
(1st para) Section 5, paragraph
starting "Because a person's location..." Location in general is
considered sensitive (not just people), and the protocol is designed to
describe more than people. |
|
133 |
5 |
Editorial |
Keith
Drage |
- 5, 1st para: Because a person's location is generally
considered to be sensitive in nature, privacy of the location
information must be protected when transmitting such information. Section 26 of [RFC3261] defines the security functionality SIPS for
transporting SIP messages with either TLS or IPSec, and S/MIME for
encrypting message bodies from SIP intermediaries that would otherwise
have access to reading the clear-text bodies. SIP endpoints SHOULD implement S/MIME to
encrypt the PIDF-LO message body (part) end-to-end
when the intended recipient is the opposite UA. The SIPS-URI from [RFC3261] MUST be implemented for message protection
(message integrity and confidentiality) and SHOULD be used when
S/MIME is not used. Possession of a dereferenceable location
URI may be equivalent to possession of the location information
itself and thus TLS SHOULD be used when sending
location-by-reference. Change "may" to "can". |
|
134 |
5 |
NIT |
Shida
Schubert |
13. Section 5, 2nd
paragraph, last sentence. > "does" or "to" is
missing. OLD: When using location-by-reference, it is RECOMMENDED that the URI not contain any
identifying information (for example use 3fg5t5yqw@example.com
rather than alice@example.com) NEW: When using location-by-reference, it is RECOMMENDED that the URI (does|to) not
contain any identifying information (for example use 3fg5t5yqw@example.com
rather than alice@example.com) |
|
135 |
5 |
Technical |
Richard
Barnes |
(2nd para) Section 5, paragraph
starting "A PIDF includes identity information..." I don't really see the
value of anonymizing the location in this case, since it's already
contained in a SIP message that has identifying information. |
|
136 |
5 |
Editorial |
Joszef
Varga |
(3rd para) The entities receiving location MUST obey
the privacy and security rules in the PIDF-LO as
described in RFC 4119, regarding retransmission and retention. - 1st line looks too short |
|
137 |
5 |
Technical |
Richard
Barnes |
(4th para) Section 5, paragraph
starting "Self-signed certificates..." This paragraph is out
of scope. It's general PIDF/GEOPRIV
concern. |
|
138 |
5 |
Technical |
Keith
Drage |
- 5, last 2 para: More than one location representation or
format, for example: civic and coordinate, MAY be included in the
same message body part, but all MUST point at the same position on the
earth. Multiple representations allow the recipient to use
the most convenient representation of location. There MAY be more than one PIDF-LO in the
same SIP message, so long as each is in a separate message body
part. Each location body part MAY point at different positions on the
earth. The meaning of such a construction is not defined, and may
cause confusion at the recipient. I would prefer that this is separated into sender and
receiver requirements, and put into the appropriate subsections within
section 5. Need to sort out the RFC 2119 language when doing so. |
|
139 |
5.1 |
Editorial |
Keith
Drage |
- 5.1, 1st para: A UAC may send location because it was
requested to, to facilitate location-based routing, or spontaneously
(i.e. a purpose not defined in this document but known to the
UAC). A UAC MAY receive location from the UAS spontaneously. Change 1st "may" to "can". |
|
140 |
5.1 |
NIT |
Shida
Schubert |
14. Section 5.1, 2nd
paragraph > The terminology for Geolocation values
seem to be inconsistent through out the document. It would be nice to have
consistency for the type of URI used in Geolocation value. May be by-value URI and
by-reference URI? |
|
141 |
5.1 |
Editorial |
Henning
Schulzrinne |
- The use of the option
tag is confusing and should be described in the UAC/UAS sections, once. |
|
142 |
5.1 |
NIT |
Shida
Schubert |
15. Section 5.1, 2nd
last paragraph > "new Warning code" sounds
like warning code yet to be defined. If you mean the warning code defined in the draft,
it's better to be explicit about it. |
|
143 |
5.1 |
Editorial |
Henning
Schulzrinne |
- The text focuses on
UAC-supplied information and only mentions a request mechanism
(Require/Supported) in passing. This should be made much clearer. What
exactly should happen if the UAC inserts a Require, but the UAS doesn't want
to provide its location? Does it need to fail the call? This seems
inappropriate. Can a UAS include location information without Supported,
e.g., for the benefit of proxies? |
|
144 |
5.1 |
Editorial |
Keith
Drage |
- 5.1, 7th para: There MAY be future work defining
additional error information, say in an XML body, indicating exactly what
the error was, if any of the new Warning codes are ambiguous. Inappropriate usage of RFC 2119 "MAY".
Rewrite: "Additional error information indicating more specifically what
the error is are outside the scope of this document, but could form the basis
of future work" - if we need to say anything at all - it would be
perfectly reasonable to delete this paragraph entirely. |
|
145 |
5.2 |
Editorial |
Henning
Schulzrinne |
- The use of the option
tag is confusing and should be described in the UAC/UAS sections, once. |
|
146 |
5.2 |
NIT |
Shida
Schubert |
16. Section 5.2, 2nd
paragraph, 1st sentence. > "to" is missing OLD: A Require header with the geolocation option
tag indicates the UAC is requiring the UAS understand this
extension or else send an error response. NEW: A Require header with the geolocation
option tag indicates the UAC is requiring the UAS to understand
this extension or else send an error response. |
|
147 |
5.2 |
Technical |
Shida
Schubert |
6. Section 5.2, 3rd
paragraph, 1st sentence. > Do we want UAS to return an error even
when location information is irrelevant to the dialog in question?
Imagine a scenario where Alice's phone is set to always convey location
info to her buddies even when the call has nothing to do with location. With
the current spec simple call which has no business with location would
fail if for example Alice's presence server is down.. Again there is
no MUST or SHOULD on this paragraph so may be it's OK. |
|
148 |
5.2 |
Technical |
Shida
Schubert |
6. Section 5.2, 3rd
paragraph, 1st sentence. > Do we want UAS to return an error even
when location information is irrelevant to the dialog in question?
Imagine a scenario where Alice's phone is set to always convey location
info to her buddies even when the call has nothing to do with location. With
the current spec simple call which has no business with location would
fail if for example Alice's presence server is down.. Again there is
no MUST or SHOULD on this paragraph so may be it's OK. |
|
149 |
5.2 |
Technical |
Shida
Schubert |
4. Section 5.2, 5th
paragraph, 2nd sentence. > "but all MUST point at the same
position on the earth." > This is not something one can
enforce, I don't think UA generally has facility to translate geo<->civic.
MUST strength seems a bit too strong here. May be SHOULD? |
|
150 |
5.2 |
Editorial |
Henning
Schulzrinne |
- The text focuses on
UAC-supplied information and only mentions a request mechanism
(Require/Supported) in passing. This should be made much clearer. What
exactly should happen if the UAC inserts a Require, but the UAS doesn't want
to provide its location? Does it need to fail the call? This seems
inappropriate. Can a UAS include location information without Supported,
e.g., for the benefit of proxies? |
|
151 |
5.2 |
Technical |
Henning
Schulzrinne |
- Normally, MIME body
parts are meant to be self-describing. What happens if somebody simply includes
a location information without any Geolocation header field? MUST this be
ignored? (I can't look it up at 35,000 feet, but isn't there a
content-disposition that should be used here?) |
|
152 |
5.2 |
Technical |
Henning
Schulzrinne |
- Is it possible for
cid and inserted-by=server to occur? I assume this means that it was inserted
by a B2BUA? What is the receiver supposed to do with this information? How
does this relate to the PIDF-LO provided-by information? |
|
153 |
5.2 |
Technical |
Joszef
Varga |
(last para) The UAS behavior for sending location is
the same as the UAC as above. - Some text for multi header
processing? E.g. info provided by a proxy has higner (lower?: operators may
not like to have a responsibility when UA inserted a location info, that can
be "better") priority |
|
154 |
5.3 |
Editorial |
Keith
Drage |
- 5.3, 1st para: [RFC3261] states message bodies cannot be
added by proxies. However, a proxy may add a header to a
message. This implies that a proxy MAY add a geolocation header with
location-by-reference, but not location-by-value. Change 1st "may" to "can". The
"MAY" is inappropriate here following the word "implies".
We have to have certainties about RFC 2119 language. |
|
155 |
5.3 |
Editorial |
Keith
Drage |
- 5.3, 3rd para: More than one Geolocation header or header
value in a message is permitted.
The meaning of such a construction is not defined, and may cause confusion at the recipient. change "may" to "can". |
|
156 |
5.3 |
Technical |
Joszef
Varga |
(4th para) Proxies that perform location-based
routing may need to consult external databases or systems to determine
the route. Transmission of the location information (which SHOULD
NOT reveal identity, even if the proxy knows the identity) is
governed by the 'retransmission-allowed' and
'routing-query-allowed': Modify to: Proxies that perform location-based
routing may need to consult external databases or systems to determine
the route. Transmission of the location information (which SHOULD
NOT reveal identity, even if the proxy knows the identity) is
governed by the appearance of the 'retransmission-allowed' and
'routing-query-allowed' values in the 'usage rules' element of ...: |
|
157 |
5.3 |
Editorial |
Keith
Drage |
- 5.3 4th
para: Proxies that perform location-based
routing may need to consult external databases or systems to determine
the route. Transmission of the location information (which SHOULD
NOT reveal identity, even if the proxy knows the identity) is
governed by the 'retransmission-allowed' and
'routing-query-allowed': change "may" to "can" |
|
158 |
5.3 |
NIT |
Shida
Schubert |
17. Section 5.3, last
paragraph. > "retransmission-allowed" and
"routing-query-allowed" is an element in the PIDF-LO but it's only mentioned in the
beginning of the draft. It may be nice to mention it again here. |
|
159 |
5.3 |
Technical |
Henning
Schulzrinne |
- Normally, MIME body
parts are meant to be self-describing. What happens if somebody simply
includes a location information without any Geolocation header field? MUST
this be ignored? (I can't look it up at 35,000 feet, but isn't there a
content-disposition that should be used here?) |
|
160 |
5.3 |
Technical |
Henning
Schulzrinne |
-
Is it possible for cid and inserted-by=server to occur? I assume this means
that it was inserted by a B2BUA? What is the receiver supposed to do with
this information? How does this relate to the PIDF-LO provided-by
information? |
|
161 |
5.3 |
Technical |
Henning
Schulzrinne |
-
The Geolocation header field seems to cause retargeting. Wouldn't it be
appropriate to indicate whether this causes the insertion of a History header
field, say? |
|
162 |
5.3 |
Technical |
Henning
Schulzrinne |
-
What should happen if a proxy tried to route on a location, failed for some
reason ("bad" URL, access denied, ....), but then routed to some
default location? Is that ok? |
|
163 |
5.3 |
Technical |
Richard
Barnes |
(4th
para) Section 5.3, paragraph
starting "Proxies that perform..." Need some text before
the colon at the end of the paragraph, e.g., "fields in a
PIDF-LO document". With regard to
the table, would it be simpler just to say
that the routing-query-allowed attribute supercedes the
retransmission-allowed element? |
|
164 |
5.3.1 |
Technical |
Rishu
Jain |
1)
Multiple Locations: |
|
165 |
5.3.1 |
Technical |
Rishu
Jain |
5)
"message-routed-on-this-uri" tells the downstream entity that |
|
166 |
5.3.1 |
Technical |
Henning
Schulzrinne |
- Removing the
message-routed-by-this-uri seems unfounded if multiple routing operations
take place. What makes the last one special? |
|
167 |
5.3.2 |
Technical |
Shida
Schubert |
7. Section 5.3.2 > Proxy sending error when there is a
location specific problem seems a bit problematic to me. I think you need
to be clear about when this is appropriate. (malformed XML, can't
decipher etc.) I think we want to prevent a case where proxy can't process
the location information properly but UAS can. The only time proxy should
return an error is if it is certain the location specific problem it
sees is also problematic to the UAS. Furthermore, we don't want proxy
not even doing location based routing to hinder a call just because it
sees problem with location. |
|
168 |
6 |
Technical |
Richard
Barnes |
Security / Privacy
Concerns: 1. In the first full
paragraph of Section says that if an emergency call using TLS fails to
complete, it MUST be retried without TLS.
I don't think it's the place of the spec to mandate UA behavior in
this case; it should be up to the user to define their urgency/privacy
trade-off. |
|
169 |
6 |
Technical |
Richard
Barnes |
Security / Privacy
Concerns: 2. In general most of
section 6 is either out of scope or true in all contexts (not just emergency
services). The only exceptions I note
are the explanatory text at the beginning and the requirement that S/MIME
MUST NOT be used in emergency cases. |
|
170 |
6 |
Technical |
Richard
Barnes |
Security / Privacy
Concerns: 3. Saying that S/MIME
MUST NOT be used for emergency calls rules out that security mechanism when
UA itself has queried a LoST server and contacts a PSAP directly. Is this intentional? |
|
171 |
6 |
Technical |
Richard
Barnes |
Security / Privacy
Concerns: 4. In Section 6, in the
second to the last paragraph, it basically says for an emergency call certain
policy flags "SHOULD" be set to "yes" and that if those
flags are set to "no" or are
not present then they may be ignored. A GEOPRIV "using protocol"
shouldn't dictate that certain policy flags be ignored for "emergency
calls" -- especially since emergency call marking is still poorly
specified. |
|
172 |
6 |
Technical |
Richard
Barnes |
Security / Privacy
Concerns: 5. On the other hand,
if you're going to allow certain policy flags to be ignored, then shouldn't
setting them to "yes" be a "MUST"? When would an entity legitimately set the
policy flags to "no" in a situation where intermediate entities are
allowed to ignore "no" values for these flags? |
|
173 |
6 |
Editorial |
Richard
Barnes |
(1st para,
bullet 2) Section 6, bullet
number 2 Remove
"s/he", reword. |
|
174 |
6 |
Editorial |
Keith
Drage |
- 6, 3rd para: Recognizing which calls are emergency
calls is beyond the scope of this document. When an emergency call is placed, location
is normally provided by the UAC. Since emergency calls must be routed based on location (and indeed, in some
jurisdictions, there may be several steps to such routing), the
location must be visible to proxies along the path. Thus S/MIME protection of location MUST NOT be
used. TLS protection of location
SHOULD be used, however, if establishment of the TLS connection fails,
the call set-up operation, including location conveyance,
MUST be retried without TLS. Firstly emergency calls must be routed on location in
some countries only. Secondly avoid pseudo RFC 2119 language. Suggest
"must" --> "can". Change "may be" to
"can be". |
|
175 |
6 |
Editorial |
Joszef
Varga |
(4th para) The entity inserting the geolocation
header MUST specify the "inserted-by" parameter, with
values of "endpoint" or "server" as appropriate. - "geolocation" à "Geolocation" |
|
176 |
6 |
Editorial |
Joszef
Varga |
(5th para) Both the
"retransmission-allowed" and "routing-query-allowed"
SHOULD be set to "yes". Querying for routing may be performed by
proxies providing a routing service for emergency
calls even if retransmission-allowed or
routing-query-allowed is set to "no" or is not present. Proxies routing on the location MUST set
the "message-routed-on-this-uri"
parameter. - insert "elements" before
"SHOULD". (or sg) |
|
177 |
6 |
Editorial |
Keith
Drage |
- 6, 5th para: Both the
"retransmission-allowed" and "routing-query-allowed"
SHOULD be set to "yes". Querying for routing may be performed by
proxies providing a routing service for emergency
calls even if retransmission-allowed or
routing-query-allowed is set to "no" or is not present. Proxies routing on the location MUST set
the "message-routed-on-this-uri"
parameter. change "may be" to "can be". |
|
178 |
6 |
Technical |
Richard
Barnes |
(6th para) Section 6, paragraph
starting "While many jurisdictions..." This should say that
many jurisdictions "require" a user to reveal a location. It seems out of scope to mandate the
configurability of positioning mechanisms. |
|
179 |
7 |
Technical |
Richard
Barnes |
(1st para) Section 7, paragraph
starting "Transmitting location information..." Remove the word
"Transmitting". Remove the
word "tracking" from "eavesdropping,
tracking, and alteration".
Replace "any protocol wishing to be
considered a GEOPRIV \"using protocol\"" with "a GEOPRIV using
protocol". Changes
"transport protocol meetings" to "transport protocol
meets". I would remove the quotes
from RFC 3693, and just cite the requirement
numbers. |
|
180 |
8 |
Editorial |
Keith
Drage |
- 8, 1st para: Conveyance of physical location of a UAC
raises privacy concerns, and depending on use, there may be
authentication and integrity concerns.
This document calls for conveyance to normally be accomplished through secure mechanisms
(like S/MIME or TLS). In cases where a session set-up is routed
based on the location of the UAC initiating the session or SIP MESSAGE,
securing the by-value location with an end-to-end mechanism such
as S/MIME is problematic, because one or more proxies on the path
need the ability to read the information to route the message
appropriately. Securing the location hop-by-hop, using TLS, protects
the message from eavesdropping and modification, but
exposes the information to all proxies on the path as well as the
endpoint. In most cases, the UAC does not know the identity of the proxy or
proxies providing location-based routing services, so that
end to middle solutions may not be appropriate either. change 1st "may" to "can". Change
"end to middle solutions may not be appropriate either" to
"end-to-middle solutions can also be inappropriate". |
|
181 |
8 |
Technical |
Richard
Barnes |
{2nd para} Section 8, paragraph
starting "When the UAC is the source ..." Change the beginning of
the first sentence to "When location is inserted by a UAC". What, exactly is being RECOMMENDED
here? Should that clause be struck? |
|
182 |
9.4 |
NIT |
Martin
Thomson |
Editorial, Minor: 3.4 & 9.4: Warnings refer to unsupported "schema". This should be "scheme"
[RFC3986]. |
|