Subject: [Geopriv] I-D Action:draft-ietf-geopriv-http-location-delivery-04.txt

From: [email-masked]
Date: Mon, 14 Jan 2008 14:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title           : HTTP Enabled Location Delivery (HELD)
	Author(s)       : M. Barnes, et al.
	Filename        : draft-ietf-geopriv-http-location-delivery-04.txt
	Pages           : 41
	Date            : 2008-01-14

A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an
access network.  The protocol includes options for retrieving
location information in two forms: by-value and by-reference.  The
protocol is an extensible application-layer protocol that is
independent of session-layer.  This document describes the use of
Hypertext Transfer Protocol (HTTP) as a transport for the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-geopriv-http-location-delivery-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-geopriv-http-location-delivery-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 14 Jan 2008 14:03:23 -0600

Hi all,

The following summarizes the changes:
1) Terminology: 
    -  clarified in terminology section that "attribute" and "element"
are used in the strict XML sense and "parameter" is used as a general
protocol term
    -  Replaced term "HTTP delivery" with "HTTP transport".  Still have
two terms "HTTP transport" and "HTTP binding", but those are consistent
with general uses of HTTP. 

2) Editorial changes and clarifications:
   - per Roger Marshall's comments
   - per Eric Arolick's comments

3) Changed normative language for describing expected and recommended
LIS behaviors to be non-normative recommendations in cases where the
protocol parameters were not the target of the discussion (e.g., we
can't prescribe to the LIS how it determines location or what it defines
to be an "accurate" location). 

4) Clarified responseTime attribute (section 6.1). Changed type from
"decimal" to "nonNegativeInteger" in XML schema (section 7)

5) Updated Table 1 in section 6 to only include top-level parameters and
fixed some errors in that table (i.e., code for locationResponse) and
adding PIDF-LO to the table. Added a detailed section describing PIDF-LO
(section 6.6), moving some of the normative text in the Protocol
Overview to this section. 

6) Added schema and description for locationURI to section 6.5.  Added
IANA registration for HELD: URI schema.

7) Added IANA registry for error codes. 

It would be most useful for past reviewers to look at the diff and make
sure you're okay with the resolution of past comments (I made slight
re-wordings to some of the things discussed on the list) and look
especially at the new content, especially the definition of the held:
URI.

One action not totally completed was to add a reference to the
draft-barnes-geopriv-lo-sec-01. I did add a reference in the security
section, but since that document isn't complete, it's hard to add any
specifics and I'm really not sure what is missing (if anything) from the
current security section and elsewhere in the document (e.g.,
recommendations for LIS generation of held: URIs to ensure that they
don't divulge any info about the device, etc.).  Also, xml2rfc wasn't
happy with my reference to that document due to it's not having a short
title or some such thing, so that needs to be fixed.

Also, I apologize in advance if I missed any particular comments, but
please do let me know if you think I've done so as it likely was not
intentional.

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 14, 2008 1:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Geopriv] I-D
Action:draft-ietf-geopriv-http-location-delivery-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Geographic Location/Privacy Working
Group of the IETF.

	Title           : HTTP Enabled Location Delivery (HELD)
	Author(s)       : M. Barnes, et al.
	Filename        :
draft-ietf-geopriv-http-location-delivery-04.txt
	Pages           : 41
	Date            : 2008-01-14

A Layer 7 Location Configuration Protocol (L7 LCP) is described that is
used for retrieving location information from a server within an access
network.  The protocol includes options for retrieving location
information in two forms: by-value and by-reference.  The protocol is an
extensible application-layer protocol that is independent of
session-layer.  This document describes the use of Hypertext Transfer
Protocol (HTTP) as a transport for the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-del
ivery-04.txt

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-ietf-geopriv-http-location-delivery-04.txt".

	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Jan 2008 14:14:47 -0600

This is a working group last call for comments on draft-ietf-geopriv- 
http-location-delivery-04.txt

Please send comments to the list or to the document editors no later  
than Tuesday January 29, 2008.

Thanks everyone for working so hard to bring this one across the  
finish line!

RjS

On Jan 14, 2008, at 1:50 PM, [email-masked] wrote:

> Content-Type: text/plain
> Content-ID: <2008-01-14144626.I-D\@ietf.org>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 14 Jan 2008 14:22:54 -0600

Hi Mary,

I have only had a cursory look so far but I noticed that the schema has
not been updated to remove the enumeration restriction on the error code
usage. This needs to happen so that implementation can actually use the
IANA error code registry.

In section 10.2 the second URI in the location URI set example is wrong.
This should have remained a SIP URI.

Cheers
James

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Tuesday, 15 January 2008 7:03 AM
> To: [email-masked]
> Cc: Robert Sparks
> Subject: RE: [Geopriv]I-D Action:draft-ietf-geopriv-http-location-
> delivery-04.txt
> 
> 
>  Hi all,
> 
is
> implementation to automatically retrieve the ASCII version of the

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]