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:
Look at the following scenario (P - is also a location recipient):

             LIS                                     LIS        
            ^  |                                      ^  |        
SUBSCRIBE |  | NOTIFY          SUBSCRIBE |  |NOTIFY
            |  |                                 |  |
UA ------->  P1 ------------------>  P2  ----------->
   INIVITE           INVITE                   INVITE

In order to take action based on "retransmission-allowed" or not,
P1 has to subscribe to the LIS (Location Information Server),
obtain the location and then take the action. The same has to be
done by all the intermediate proxies. So is this not a overhead?

 

5

General

Technical

Rishu Jain

3) "retransmission-allowed"
Even if "retransmission-allowed" value is set to "no", can the
proxy remove the PIDF location object from the message? RFC 3261
does not allow any proxy to add or delete the message body. So what
is the use of "retransmission-allowed" with value "yes" or "no"?

 

6

General

Technical

Rishu Jain

4) What is the behavior in following case:

Retransmission-allowed Routing-query-allowed Transmission for Query
---------------------- --------------------- ----------------------
        "no"                  not present           ?????

 

7

General

Technical

Rishu Jain

7) <sips: username@server.com> or <sips:server.com/username>
are these same? Is the second form a valid SIP URI?

 

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.
Callee would have subscribed to that identity and would get the
caller's location. Now if caller's identity is changed and caller
sent a new RE-INVITE message. Should callee then stop subscription
with first location and should subscribe to the new location?
There is no behaviour with respect to this is mentioned in UAS scope?

 

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
Methods are allowed, although no purpose is known.  Conveying
location in a CANCEL, BYE, ACK or PRACK is not defined.  

Conveying location in "BYE" is defined or not?

 

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: