Subject: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.txt

From: [email-masked]
Date: Thu, 24 Feb 2011 18:00:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : Location Conveyance for the Session Initiation Protocol
	Author(s)       : J. Polk, et al.
	Filename        : draft-ietf-sipcore-location-conveyance-06.txt
	Pages           : 29
	Date            : 2011-02-24

This document defines an extension to the Session Initiation 
Protocol (SIP) to convey geographic location information from one 
SIP entity to another SIP entity.  The SIP extension covers 
end-to-end conveyance as well as location-based routing, where SIP 
intermediaries make routing decisions based upon the location of the
Location Target.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Feb 2011 19:10:10 -0500

James,

A few things...

Section 4.1:

    Additionally, the first SIP intermediary to add a locationValue adds
    it as the last locationValue in the header value. A SIP intermediary
    that adds a locationValue MUST position it as the last locationValue
    of the last Geolocation header field of the message.

John E already called this out, and I agree.
The first sentence ("Additionally...header value.") should be removed. 
The subsequent sentence covers all that and more.

(There is nothing special about the *first* intermediary to add 
locationValue.)

In the same section:

    This document defines the Geolocation header field as valid in the
    following SIP requests:

       INVITE [RFC3261],             REGISTER [RFC3261],
       OPTIONS [RFC3261],            BYE [RFC3261],
       UPDATE [RFC3311],             INFO [RFC2976],
       MESSAGE [RFC3428],            REFER [RFC3515],
       SUBSCRIBE [RFC3265],          NOTIFY [RFC3265],
       PUBLISH [RFC3903],            PRACK [RFC3262]

This isn't new, and maybe it came up before (I don't recall), but was 
there a reason why PRACK is in this list? I can't think of a good reason 
to put Geoloc info in PRACK, and PRACK is a message that really should 
not be rejected. Geoloc info provides another potential reason why a 
recipient might find a need to reject it.

Unless there is some history on this point, and particular reason for 
including PRACK, I propose that it be removed from the list.

Section 4.4:

    message-header          /= Geolocation-Error-header ;
                                 (message-header from 3261)
    Geolocation-Error        = "Geolocation-Error" HCOLON
                                 locationErrorValue

The name used in the two statements is not consistent. Change the first:

    message-header /= Geolocation-Error ; (message-header from 3261)

Section 8:

I don't see anything to register the Geolocation-Error header.
Did that get missed up till now?

	Thanks,
	Paul