Comments on: draft-ietf-sip-location-conveyance-07

 

Detailed review comments received from at least:

·        Richard Barnes (rbarnes@bbn.com)

·        Keith Drage (drage@alcatel-lucent.com)

·        Rishu Jain (rishu.jain@aricent.com)

·        Shida Schubert (shida@ntt-at.com)

·        Henning Schulzrinne (hgs@cs.columbia.edu)

·        Umesh Sharma (USharma@veraznet.com)

·        Hannes Tschofenig (Hannes.Tschofenig@gmx.net)

·        Joszef Varga (jozsef.varga@nsn.com)

 

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)

 

31A

1

Editorial

Hannes Tschoenig

The introduction seems to have grown over time and at several paragraphs it now says "This document" or in "In this document"

Maybe someone would like to ensure that it reads nicely rather than patched together.

 

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"

 

32A

1

Editorial

Hannes Tschoenig

 
"
   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.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^

 

"

 

Either write using SIP [..] or using the Session Initiation Protocol [...].

 

 

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.

 

33A

1

Technical

Hannes Tschoenig

Change from:

 

"

   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.

"

to:

 

"

   This document describes how geodetic and/or civic location

   information can be conveyed 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.

 

   This document does not describe mechanisms for subscription and

   notification.

"

 

Regarding the last sentence I wonder why you this document indicates that Geolocation header may appear in a SUBSCRIBE / NOTIFY message.

 

 

 

33B

1

Technical

Hannes Tschoenig

Regarding:

"

   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.

"

 

I am not sure that this document is associating semantic to the location information with respect to the UAC. It just carries the location information from A to B. I believe that the information carried inside the PIDF (entity attribute) would tell to which entity this location information refers to.

 

 

 

33C

1

Technical

Hannes Tschoenig

Regarding:

 

"Conveyance is a push model, where seeking is a pull model, and

   therefore not discussed here.

"

 

I would omit this push vs. pull discussion since the draft also talks about LbyR and then these things get fuzzy.

 

Please use the following terms as capitalized words since they refer to terms introduced in the GEOPRIV requirement RFC. We did this in other docs as well: target => Target, using protocol => Using Protocol, location server => Location Server, location object => Location Object, location recipient => Location Recipient

 

 

 

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

 

35A

General

Editorial

Hannes Tschoenig

 
The term 'Location' is written with a capital letter (see for example first

 

paragraph in Section 1) whereas other RFC3693 terms that are meant to be

 

written with a capital letter aren't (example: 'target', 'location object',

 

'using protocol', 'location recipient'). I suggest to stick with RFC3693.

 

 

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)

 

38A

1

Editorial

Hannes Tschoenig

Regarding:

"

A

   PIDF-LO is an XML Schema specifically for carrying geographic

   location of a thing.

"

 

A PIDF-LO is an XML document extending PIDF to carry location information.

 

 

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

 

38A

1

Editorial

Hannes Tschoenig

 
I suggest to rewrite the following paragraph from:

 

"
   As recited in RFC3693, 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.

 

"

 

to:

 

"
   The
   Location Object contains rules which provide guidance for the Location


Recipient on the onward distribution and retention of
the received location information. This document describes the security

and privacy
   considerations that must be applied to location conveyed with SIP.
"

 

 

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".

 

 

41A

1

Editorial

Hannes Tschoenig

I don't know what this sentence should mean in Section 1 at this part of the

section.
"
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.
"

 

There seems to be a copy-and-paste problem.

 

 

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".

 

 

43A

1

Editorial

Hannes Tschoenig

 
You write:

 

"
   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 UAs PIDF-LO, or a
   location-by-reference URI that may subsequently be "dereferenced" by
   a using protocol (which may be SIP or another protocol).
"


Please delete the following part " by
a using protocol (which may be SIP or another protocol)" since we haven't

concluded in our discussion that the dereferencing protocol is indeed a

 

using protocol.

 

Actually, I think that the entire paragraph is not particularly useful in

 

the introduction and the subsequent paragraph fits much better to the

 

previous one.

 

 

43B

1

Technical

Hannes Tschoenig

Emergency case:

 

I believe that all occurrences of emergency services should be deleted from the document since this document is generic in its nature. Let the Phone BCP deal with the emergency issue since it has todo so anyway

 

 

43C

1

Editorial

Hannes Tschoenig

Last para

Put a comma before "which".

Put a comma after "i.e." and "e.g."

 

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?

 

60A

3.1

Technical

Hannes Tschoenig

"message-routed-on-this-uri":

 

 This functionality was introduced quite late in the process.

 If I recall it correctly then it would be used for debugging purposes.

 Is this correct? (nothing more - right?)

 

 

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

 

61A

3.1

Technical

Hannes Tschoenig

"retransmission-allowed":

 

With the "retransmission-allowed" element, the rule maker can control distribution of the location information for location-based routing.

It is clear how these rules are set with location information being added by an end point. In that particular case it is implicit that the end point want to use location information for routing. If it would not want to use location information for routing it would have to encrypt it anyway.

 

Hence, is this functionality really necessary?

 

 

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]

 

64A

3.2

Editorial

Hannes Tschoenig

 
You write:
"
The Geolocation header MUST contain one two types of URIs:
                                    ^^^^^^^^^^^^
                                    one of two types

"

 

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.

 

75A

3.2

Technical

Hannes Tschoenig

 
* Privacy Rules

 

You write:
"
   Entities receiving location information MUST honor the usage element
   rules per RFC4119.  Such entities MUST NOT alter the rule set.
"

 

The last sentence is not correct. Let me give you an example: A SIP UAC

 

obtains location information from GPS and uses a PUBLISH to upload the

 

PIDF-LO to the Location Server/ Presense Server. This server has rules that

 

control access to location information. As part of these rules the content

 

of the Location Object including the rules might be modified.

 

 

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?

 

101A

3.4.9

Technical

Hannes Tschoenig

This document talks about a LIS but does not define what it is :-)

 

 

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

 

116A

3.6

Question

Hannes Tschoenig

 
Questions:

 



You write:
"

 

   A dereference of a location-by-reference URI using SUBSCRIBE is not
   violating a PIDF-LO 'retransmission-allowed' element value set to
   'no', as the NOTIFY is the only message in this multi-message series
   of transactions that contains the UAC's location, with the location
   recipient being the only SIP element to receive location - which the
   purpose of this extension: to convey location to a specific
   destination.
"

 

I wasn't quite sure what you are about to say with this statement. If the

 

Location Recipient receives a reference and it resolves it then you are

 

saying that this is OK even if the retransmission-allowed flag says "no".

 

Correct?

 

 

116B

3.6

Technical

Hannes Tschoenig

 
* Using Protocol

 

You write:
"
   Other protocols used in the Location URI MUST be reviewed against
   the RFC3693 criteria for a using protocol.
"

 

Later, in Section 3.6 you write:
"
Use of other protocols for dereferencing
   of a pres: URI is not defined, and such use is subject to review
   against RFC3693 using protocol criteria.
"


I disagree that the protocol used to resolve the reference has to be a using

protocol. Hence, I suggest to delete this sentence.
 

 

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.

 

117A

4

Technical

Hannes Tschoenig

* The examples pick unfortunate references (sips:server5.atlanta.example.com/alice123)
that give me the impression that the reference contains the user identity.
The document clearly needs to point out that this is not the case. The document also does not indicate

that the reference is only kept for a certain period of time (soft-state).
The document does not even mention security aspects when retrieving the

 

reference.

 

 

117B

4

Editorial

Hannes Tschoenig

 
The example contains a company name

 

(<gp:provided-by>www.cisco.com</gp:provided-by>) although it should,

 

according to the guidelines something like "www.example.com".

 

 

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').

 

129A

4.3

Editorial

Hannes Tschoenig

 
Section 4.3 uses the term 'LIS' and does not mention what it is.
Just avoid it.

 

129B

4.3

Technical

Hannes Tschoenig

Delete this statement:

"

 This will likely

   not suit some services already being considered in the IETF at the

   time of this writing, such as emergency calling.

"

 

 

129C

5

Technical

Hannes Tschoenig

 
* Security in Section 5 SIP Element Behavior

 

I am confused with the text in Section 5. What MUST and what SHOULD be used

 

when protecting a location-by-value and a location-by-reference?

 

SHOULD for TLS usage with location-by-value and location-by-reference.
No statement about usage of S/MIME.

 

I wonder why self-signed certificates shouldn't be used as stated with:
"
   Self-signed certificates SHOULD NOT be used for protecting PIDF,
   as the sender does not have a secure identity of the recipient.
"
For encryption (and that's what we are talking about here) it heavily

 

depends on the way how the self-signed certificate was obtained. I might

 

share my certificate with you and hence that's an extemely useful way todo

 

compared to the usage of TLS in a hop-by-hop way where a number of entities

 

see my location along the path.


Identity info in the PIDF. In previous discussion I was wondering and asking

the Geopriv group whether there is some semantic associated with the

 

identity in the PIDF. If there is, then you cannot put anything you like

 

into the PIDF. If there isn't then why should we ever want to put something

 

meaningful in there since it greatly impacts the privacy risks.


I see a problem with retargeting and forking where the Location Recipient is actually not know ahead of time and S/MIME usage is actually not really feasible. Would some guidance be useful?

 

129D

5

Technical

Hannes Tschoenig

Section 5:

"

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.

"

 

What does this mean?

 

You always have to use TLS when you do not use S/MIME regardless whether you send it by value or by reference.

Exception: Emergency Services

 

 

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?

 

143A

5.1

Technical

Hannes Tschoenig

Section 5.1:

"

   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.

"

 

Delete this sentence -- RFC 2119 language not appropriate.

 

 

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.

 

144A

5.1

Technical

Hannes Tschoenig

Section 5.1:

 

"

 This is a seeking or

   pull model scenario, which is not defined here, and left for future

   study.

"

 

This document defines the ability to carry location information in a SUBSCRIBE/NOTIFY exchange.

Let's assume it wouldn't be defined in this document then it would be available already via the rest of the presence work

 

 

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

 

153A

5.3

Technical

Hannes Tschoenig

 
* Proxy Usage

 

When a proxy adds a reference to a PIDF-LO then a number of issues remain

 

unclear (as discussed throughout the Geopriv work), namely:

 

  - What does the PIDF-LO contain that is created by the SIP proxy?

 



* How does the proxy know that location information has to be added?

 

  - There is a privacy problem if the SIP proxy acts without explicit

 

indication that location information is added.

 

 

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:
- Section 5.3.1
A server/proxy can add gelocation value to the existing geolocation
header provided by UAC. In that case the messsage would look like this:

Geolocation: <cid:alice123@atlanta.example.com>; inserted-by=endpoint,
                    <sips:3sdefrhy2jj7@lis.atlanta.example.com>;
                    inserted-by=server;

=>How the location recipient will decide which location is to
be referred to? Either the one provided in the Sip message (CID URI)
or he has to subscribe to the location provided in SIPS URI?

 

165

5.3.1

Technical

Rishu Jain

5) "message-routed-on-this-uri" tells the downstream entity that
is was routed based on location once. In section  5.3.1 it is
mentioned that in case multiple times if routing is done based on
location still only one latest entry of "message-routed-on-this-uri"
is sufficient.

Why downstrem entity need to know that only one routing has
happened (if at all it needs to know)? Why it need not find out
multiple location based routing was done?

 

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.

 

167A

6

Technical

Hannes Tschoenig

Emergency case:

 

I believe that all occurrences of emergency services should be deleted from the document since this document is generic in its nature. Let the Phone BCP deal with the emergency issue since it has todo so anyway

 

 

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.

 

179A

7

Technical

Hannes Tschoenig

 
* Section 7.


The document refers to 'using protocols' for both the UAC <-> UAS and to the dereferencing protocol. I assume that Section 7 only addresses the UAC <-> UAS communication. Since I am in favor of not treating the derefencing protocol a 'using protocol' I am fine with it.

Actually, I would prefer to move Section 7 into the appendix since this is just such an artifical story that it makes me nervous. It is not your fault; it is just the way how RFC 3693 was written.

 

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?

 

181A

8

Technical

Hannes Tschoenig

* The security consideration section isn't particularly good. If I have time I rewrite it.

 

181B

8

Technical

Hannes Tschoenig

The security consideration is far too short for this sensitive topic.

 

182

9.4

NIT

Martin Thomson

Editorial, Minor:  3.4 & 9.4:  Warnings refer to unsupported "schema".  This should be "scheme" [RFC3986].