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?