Monday, December 28, 2009

Re: [Geopriv] draft-ietf-geopriv-loc-filters-08 element placement

Thanks for your feedback, Martin.

I have incorporated your comments into the most recent draft update:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-09.tx
t

Ciao
Hannes

>-----Original Message-----
>From: geopriv-bounces@ietf.org
>[mailto:geopriv-bounces@ietf.org] On Behalf Of ext Thomson, Martin
>Sent: 27 November, 2009 07:21
>To: geopriv@ietf.org
>Subject: [Geopriv] draft-ietf-geopriv-loc-filters-08 element placement
>
>Regarding the placement of the newly defined XML elements in
>the filter document.
>
>The new <moved> and <enterOrExit> elements should be a child
>of the RFC4661 <trigger> element, not a direct child of
><filter>. Similarly, the <locationType> element should be a
>child of the <what> element.
>
>The <filter> element does allow for extension, but the
><trigger> element is more appropriate for these additions as
>they describe events that *trigger* notification. Same goes
>for locationType.
>
>The examples become...
>
>...in 3.1:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <filter-set
> xmlns="urn:ietf:params:xml:ns:simple-filter"
> xmlns:lf="urn:ietf:params:xml:ns:location-filter">
> <filter id="123" uri="sip:presentity@example.com">
> <trigger>
> <lf:moved>300</lf:moved>
> </trigger>
> </filter>
> </filter-set>
>
>...in 3.4:
>
> <filter-set
> xmlns="urn:ietf:params:xml:ns:simple-filter"
> xmlns:lf="urn:ietf:params:xml:ns:location-filter"
> xmlns:gml="http://www.opengis.net/gml"
> xmlns:gs="http://www.opengis.net/pidflo/1.0">
>
> <filter id="123" uri="sip:presentity@example.com">
> <trigger>
> <lf:enterOrExit>
> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
> <gml:pos>42.5463 -73.2512</gml:pos>
> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
> 850.24
> </gs:radius>
> </gs:Circle>
> </lf:enterOrExit>
> </trigger>
> </filter>
> </filter-set>
>
>...and:
>
> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
> xmlns:lf="urn:ietf:params:xml:ns:location-filter"
> xmlns:gml="http://www.opengis.net/gml">
>
> <filter id="123" uri="sip:presentity@example.com">
> <trigger>
> <lf:enterOrExit>
> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
> <gml:exterior>
> <gml:LinearRing>
> <gml:pos>43.311 -73.422</gml:pos> <!--A-->
> <gml:pos>43.111 -73.322</gml:pos> <!--F-->
> <gml:pos>43.111 -73.222</gml:pos> <!--E-->
> <gml:pos>43.311 -73.122</gml:pos> <!--D-->
> <gml:pos>43.411 -73.222</gml:pos> <!--C-->
> <gml:pos>43.411 -73.322</gml:pos> <!--B-->
> <gml:pos>43.311 -73.422</gml:pos> <!--A-->
> </gml:LinearRing>
> </gml:exterior>
> </gml:Polygon>
> </lf:enterOrExit>
> </trigger>
> </filter>
> </filter-set>
>
>Section 3.5: The new locationType element belongs in a <what> element:
>
> <filter-set
> xmlns="urn:ietf:params:xml:ns:simple-filter"
> xmlns:lf="urn:ietf:params:xml:ns:location-filter">
> <filter id="123" uri="sip:presentity@example.com">
> <what>
> <lf:locationType exact="true">
> geodetic
> </lf:locationType>
> </what>
> </filter>
> </filter-set>
>
>There's also the comment in the schema and some text that
>might need tweaking, especially in the top of Section 3
>regarding a profile of 4661.
>
>And while you're at it; the <?xml version...?> tags aren't
>necessary; remove 'em.
>
>Apologies for missing this earlier. It's not a big thing, and
>the doc can probably live without this, but it would be better
>if this were done correctly.
>
>--Martin
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-loc-filters-09.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 : Filtering Location Notifications in the Session Initiation Protocol (SIP)
Author(s) : R. Mahy, et al.
Filename : draft-ietf-geopriv-loc-filters-09.txt
Pages : 23
Date : 2009-12-28

This document describes filters that limit asynchronous location
notifications to compelling events, designed as an extension to RFC
4661, an XML-based format for event notification filtering, and based
on RFC 3856, the SIP presence event package. The resulting location
information is conveyed in existing location formats wrapped in the
Presence Information Data Format Location Object (PIDF-LO).

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 1, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-09.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.

Re: [Geopriv] WGLC for draft-rosen-geopriv-prefix-00 ends Monday

Hi Alissa,

My feedback is a little late. The document looks good and I have only a
few editorial suggestions.

Ciao
Hannes

Network Working Group B. Rosen
Internet-Draft NeuStar
Intended status: Informational July 3, 2009
Expires: January 4, 2010


Prefix elements for Road and House Numbers in PIDF-LO

[hannes] Prefix Elements for Road and House Numbers for
the
Presence Information Data Format Location Object
(PIDF-LO)

draft-rosen-geopriv-prefix-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 4, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Abstract

RFC4119 updated by RFC5139 defines suffixes for street names and
house numbers, but does not define prefixes. Both occur regularly in
addresses and CAtypes are needed for them. This memo defines STP

[hannes] civic address types (CAtypes)


Rosen Expires January 4, 2010 [Page 1]

Internet-Draft Road and House Prefix July 2009


Street Prefix and HNP house number prefix CAtypes.

[hannes] ... defines the Street Prefix (STP) and the House Number Prefix
(HNP)
CAtypes.

Table of Contents

1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Prefixes in addressing . . . . . . . . . . . . . . . . . . 3
1.2. Security Considerations . . . . . . . . . . . . . . . . . . 3
1.3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 3
2. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Normative References . . . . . . . . . . . . . . . . . . . 3
2.2. Informative References . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4


Rosen Expires January 4, 2010 [Page 2]

Internet-Draft Road and House Prefix July 2009

[hannes] change the section headings

--------

1. Introduction
--> current Section 1.1

2. Terminology

--> current Section 1

3. Security Considerations

--> currently Section 1.2

4. IANA Considerations

--> currently Section 1.3

---------

1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

1.1. Prefixes in addressing

In [RFC4119] one can define a PIDF for 123 Main Street but not 123

[hannes] RFC 4119 [RFC4119] allows to create a PIDF for 123 Main
Street.....

Boulevard Coranado. There is an STS CAtype for a suffix, but no
corresponding prefix. [RFC5139] added PRM Premodifier and POM
Postmodifier, but those are not suitable for the purpose.


[hannes] [RFC5139] added the PRM Premodifier and POM
Postmodifier CAtypes, but those are not suitable for the purpose.


Similarly, one can express 123B Main, but not H123 Main. Although
one can include such letters in the house number, most addressing
authorities keep the number numeric only to facilitate sorting, and
have prefix and suffix fields for alphanumerics that appear in front
of or following the numeric house number.

To remedy this situation, new CAtypes are required: STP for a street
(road) prefix, and HNP for a house number prefix.

1.2. Security Considerations

The XML representation described in this document is designed for
inclusion in a PIDF-LO document. As such, it is subject to the same
security considerations as are described in [RFC4119].
Considerations relating to the inclusion of this representation in
other XML documents are outside the scope of this document.

1.3. IANA Considerations

This document updates the civic address type registry established by
[RFC4776]. Two additional value are added:

41 STP Street (Road) Prefix
42 HNP House Number Prefix


2. References

2.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.

Rosen Expires January 4, 2010 [Page 3]

Internet-Draft Road and House Prefix July 2009


2.2. Informative References

[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.

[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.


Author's Address

Brian Rosen
NeuStar, Inc.
470 Conrad Dr
Mars, PA 16046
US

Email: br@brianrosen.net

Rosen Expires January 4, 2010 [Page 4]

>-----Original Message-----
>From: geopriv-bounces@ietf.org
>[mailto:geopriv-bounces@ietf.org] On Behalf Of ext Alissa Cooper
>Sent: 22 November, 2009 07:59
>To: GEOPRIV
>Subject: [Geopriv] WGLC for draft-rosen-geopriv-prefix-00 ends Monday
>
>Just a reminder that the WGLC for
>draft-rosen-geopriv-prefix-00 ends Monday, November 23. Please
>send comments to the list if you have them.
>
>Alissa
>
>
>>
>> In September we took a consensus call on adopting draft-rosen-
>> geopriv-prefix-00 as a working group item. As the draft is extremely
>> straightforward, we are taking it directly to WGLC. An associated
>> milestone has been approved.
>>
>> Thus, this is a GEOPRIV Working Group Last Call for comments on
>> draft-rosen-geopriv-prefix-00
>> (http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt)
>>
>> Please send your comments no later than Monday, November 23, 2009.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Thursday, December 17, 2009

Re: [Geopriv] [geopriv] #3: GML Mapping

#3: GML Mapping
--------------------------------+-------------------------------------------
Reporter: rbarnes@… | Owner: martin.thomson@…
Type: defect | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version:
Severity: Active WG Document | Keywords:
--------------------------------+-------------------------------------------

Comment(by bernard_aboba@…):

I have incorporated Section 3 into Appendix B within -04. This does not
include GML examples, however.

For details, see:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-04.txt

--
Ticket URL: <https://wiki.tools.ietf.org/wg/geopriv/trac/ticket/3#comment:7>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-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 : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information
Author(s) : J. Polk, et al.
Filename : draft-ietf-geopriv-rfc3825bis-04.txt
Pages : 25
Date : 2009-12-17

This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes
latitude, longitude, and altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference
datum for each of these values.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-04.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.

Re: [Geopriv] [geopriv] #4: Uncertainty semantic for resolution fields

#4: Uncertainty semantic for resolution fields
-----------------------------+----------------------------------------------
Reporter: rbarnes@… | Owner: jmpolk@…
Type: defect | Status: closed
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version:
Severity: - | Resolution: fixed
Keywords: |
-----------------------------+----------------------------------------------
Changes (by bernard_aboba@…):

* status: new => closed
* resolution: => fixed


Comment:

In -04, Appendix B has been added to include the additional example
provided by Martin, and the requested changes have been applied.

Section 1.2 has been updated to include a definition of resolution. In
addition, sections
have been added describing Longitude, Latitude and Altitude resolution.

Throughout the document, the LoRes/LaRes/AltRes terminology has been
changed to LongUnc/LatUnc/AltUnc, to correspond to the names of the fields
defined in Sections 2.1 and 2.2. The title of Appendix A (and the first
paragraph) has been changed to make it clear that this Appendix involves
calculation of resolution. The Appendix B title and introductory
paragraph indicate that this section involves calculation of uncertainty.

--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/4#comment:7>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Wednesday, December 16, 2009

Re: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

I agree with the draft's approach, and consider this extension as a
"must-have". Please move this draft toward standardization.

-roger marshall.

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Alissa Cooper
> Sent: Tuesday, December 15, 2009 2:52 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00
>
> We issued a WGLC on draft-rosen-geopriv-prefix-00
> (http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt
> ) on November 2, and it ended on November 23. There were no comments
> to the list about the document during the WGLC. To progress this
> document, we need some indication from people (other than the author)
> that this is worth standardizing. If you think it's a good document,
> please send a quick note to the list saying so before the end of the
> week.
>
> Thanks,
> Alissa
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

I agree with the draft, and see a need for the CAType prefixes.
I would like to see it made part of the standard.

Avery

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Alissa Cooper
> Sent: Tuesday, December 15, 2009 4:52 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00
>
> We issued a WGLC on draft-rosen-geopriv-prefix-00
> (http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt
> ) on November 2, and it ended on November 23. There were no comments
> to the list about the document during the WGLC. To progress this
> document, we need some indication from people (other than the author)
> that this is worth standardizing. If you think it's a good document,
> please send a quick note to the list saying so before the end of the
> week.
>
> Thanks,
> Alissa
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

I think this is a good document, and worth standardizing.
Barbara

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Alissa Cooper
> Sent: Tuesday, December 15, 2009 5:52 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00
>
> We issued a WGLC on draft-rosen-geopriv-prefix-00
> (http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt
> ) on November 2, and it ended on November 23. There were no comments
> to the list about the document during the WGLC. To progress this
> document, we need some indication from people (other than the author)
> that this is worth standardizing. If you think it's a good document,
> please send a quick note to the list saying so before the end of the
> week.
>
> Thanks,
> Alissa
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

The draft-rosen-geopriv-prefix-00.txt allows a standardized method of
capturing address numbering and street (road) naming schemes that exist
today which do not fit the current [RFC4119] PIDF schema. Rather than trying
to "force" these unique address numbering and street naming schemes the
draft-rosen-geopriv-prefix-00.txt allows for a more consistent and
standardized method of properly capturing these types of numbering and
naming conventions.

Thanks,
Marc B.

Marc E. Berryman, ENP
9-1-1 Services Director
Digital Data Technologies, Inc.
Celebrating 10 years in GIS and 9-1-1
mberryman@ddti.net
614-429-3384 - Ext 247
888-800-4003

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of Alissa Cooper
Sent: Tuesday, December 15, 2009 5:52 PM
To: geopriv@ietf.org
Subject: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

We issued a WGLC on draft-rosen-geopriv-prefix-00
(http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt
) on November 2, and it ended on November 23. There were no comments
to the list about the document during the WGLC. To progress this
document, we need some indication from people (other than the author)
that this is worth standardizing. If you think it's a good document,
please send a quick note to the list saying so before the end of the
week.

Thanks,
Alissa


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Tuesday, December 15, 2009

Re: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

I agree with this document regarding Prefix elements for Road and House
Numbers being added to PIDF-LO.

Thank you,
Delaine M. Arnold, ENP
Independent Consultant
Chair, NENA Data Technical Committee
813-960-1698


-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of Alissa Cooper
Sent: Tuesday, December 15, 2009 5:52 PM
To: geopriv@ietf.org
Subject: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

We issued a WGLC on draft-rosen-geopriv-prefix-00
(http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt
) on November 2, and it ended on November 23. There were no comments
to the list about the document during the WGLC. To progress this
document, we need some indication from people (other than the author)
that this is worth standardizing. If you think it's a good document,
please send a quick note to the list saying so before the end of the
week.

Thanks,
Alissa


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.txt

Scanning for MUSTs is a great way of implementing a standard. Personally, I prefer to scan for examples. Failing that, I look for pictures. Sequence diagrams and flow charts are pretty good.

;)

> -----Original Message-----
> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
> Sent: Tuesday, 15 December 2009 1:41 AM
> To: Thomson, Martin
> Cc: Alissa Cooper; geopriv@ietf.org
> Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-
> 13.txt
>
> <hat type="individual"/>
>
> At the same time, though, it's very important for network operators to
> know what clients are going to do. I'm a fan of using RFC 2119
> language effectively as a keyword, so that an implementor can scan
> through looking for the MUSTs to figure out what he has to do. But
> I'm not hard over on this issue, it's a matter of style.
>
> --Richard
>
>
>
> On Dec 13, 2009, at 6:10 PM, Thomson, Martin wrote:
>
> > Personal prejudice against overuse of 2119 language, mostly.
> >
> > I try not to use 2119 language to describe basic behaviour like
> > this. It's overkill. It makes documents seem dictatorial. It's
> > also harder to read. It also reduces the impact of 2119 language in
> > those places where it is really important.
> >
> > Imagine if every part of the process describe in this document used
> > MUST, starting with the procedure described in Section 2...
> >
> > --Martin
> >
> >> -----Original Message-----
> >> From: Alissa Cooper [mailto:acooper@cdt.org]
> >> Sent: Monday, 14 December 2009 12:43 AM
> >> To: Thomson, Martin
> >> Cc: geopriv@ietf.org
> >> Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-
> >> 13.txt
> >>
> >> Hi Martin,
> >>
> >> In the new parts about DHCPv4 option 15, can you explain why you
> >> don't
> >> use 2119 language? In both section 2 and section 3.4 you say that
> >> DHCPv4 option 15 "is used" (as opposed to, e.g., "SHOULD be used"),
> >> so
> >> it sounds like you're stating a fact rather than giving a direction
> >> to
> >> implementers.
> >>
> >> Thanks,
> >> Alissa
> >>
> >> On Dec 8, 2009, at 9:21 PM, Thomson, Martin wrote:
> >>
> >>> In addition to the minor changes suggested on the list, this latest
> >>> version addresses comments that came up in the AD review.
> >>>
> >>> The document is now less negative towards use of DHCPv4 option 15.
> >>> Section 4.1 has been moved to Section 3.4 and Section 3 has been
> >>> renamed accordingly. There is also a flow chart that should make
> it
> >>> easy for implementers to understand how all the pieces fit
> together.
> >>>
> >>> The diff shows the changes:
> >>>
> >>> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lis-
> >> discovery-13.txt
> >>>>
> >>>
> >>> --Martin
> >>>
> >>>> -----Original Message-----
> >>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
> On
> >>>> Behalf Of Internet-Drafts@ietf.org
> >>>> Sent: Wednesday, 9 December 2009 12:30 PM
> >>>> To: i-d-announce@ietf.org
> >>>> Cc: geopriv@ietf.org
> >>>> Subject: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-
> >> 13.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 : Discovering the Local Location Information
> >>>> Server (LIS)
> >>>> Author(s) : M. Thomson, J. Winterbottom
> >>>> Filename : draft-ietf-geopriv-lis-discovery-13.txt
> >>>> Pages : 17
> >>>> Date : 2009-12-08
> >>>>
> >>>> Discovery of the correct Location Information Server (LIS) in the
> >>>> local access network is necessary for devices that wish to acquire
> >>>> location information from the network. A method is described for
> >> the
> >>>> discovery of a LIS in the access network serving a device.
> Dynamic
> >>>> Host Configuration Protocol (DHCP) options for IP versions 4 and 6
> >>>> are defined that specify a domain name. This domain name is then
> >>>> used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
> >>>>
> >>>> Status of This Memo
> >>>>
> >>>> This Internet-Draft is submitted to IETF in full conformance with
> >> the
> >>>> provisions of BCP 78 and BCP 79.
> >>>>
> >>>> Internet-Drafts are working documents of the Internet Engineering
> >>>> Task Force (IETF), its areas, and its working groups. Note that
> >>>> other groups may also distribute working documents as Internet-
> >>>> Drafts.
> >>>>
> >>>> Internet-Drafts are draft documents valid for a maximum of six
> >> months
> >>>> and may be updated, replaced, or obsoleted by other documents at
> >>>> any
> >>>> time. It is inappropriate to use Internet-Drafts as reference
> >>>> material or to cite them other than as "work in progress."
> >>>>
> >>>> The list of current Internet-Drafts can be accessed at
> >>>> http://www.ietf.org/ietf/1id-abstracts.txt.
> >>>>
> >>>> The list of Internet-Draft Shadow Directories can be accessed at
> >>>> http://www.ietf.org/shadow.html.
> >>>>
> >>>> This Internet-Draft will expire on June 11, 2010.
> >>>>
> >>>> Copyright Notice
> >>>>
> >>>> Copyright (c) 2009 IETF Trust and the persons identified as the
> >>>> document authors. All rights reserved.
> >>>>
> >>>> This document is subject to BCP 78 and the IETF Trust's Legal
> >>>> Provisions Relating to IETF Documents
> >>>> (http://trustee.ietf.org/license-info) in effect on the date of
> >>>> publication of this document. Please review these documents
> >>>> carefully, as they describe your rights and restrictions with
> >> respect
> >>>> to this document. Code Components extracted from this document
> >>>> must
> >>>> include Simplified BSD License text as described in Section 4.e of
> >>>> the Trust Legal Provisions and are provided without warranty as
> >>>> described in the BSD License.
> >>>>
> >>>> A URL for this Internet-Draft is:
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-
> >> discovery-
> >>>> 13.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.
> >>> _______________________________________________
> >>> Geopriv mailing list
> >>> Geopriv@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/geopriv
> >>>
> >>
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Feedback on draft-rosen-geopriv-prefix-00

I like it, we need it. Progress the document.

-Marc-


On 12/15/09 5:52 PM, "Alissa Cooper" <acooper@cdt.org> wrote:

> We issued a WGLC on draft-rosen-geopriv-prefix-00
> (http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt
> ) on November 2, and it ended on November 23. There were no comments
> to the list about the document during the WGLC. To progress this
> document, we need some indication from people (other than the author)
> that this is worth standardizing. If you think it's a good document,
> please send a quick note to the list saying so before the end of the
> week.
>
> Thanks,
> Alissa
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Feedback on draft-rosen-geopriv-prefix-00

We issued a WGLC on draft-rosen-geopriv-prefix-00 (http://tools.ietf.org/id/draft-rosen-geopriv-prefix-00.txt
) on November 2, and it ended on November 23. There were no comments
to the list about the document during the WGLC. To progress this
document, we need some indication from people (other than the author)
that this is worth standardizing. If you think it's a good document,
please send a quick note to the list saying so before the end of the
week.

Thanks,
Alissa


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Monday, December 14, 2009

Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.txt

<hat type="individual"/>

At the same time, though, it's very important for network operators to
know what clients are going to do. I'm a fan of using RFC 2119
language effectively as a keyword, so that an implementor can scan
through looking for the MUSTs to figure out what he has to do. But
I'm not hard over on this issue, it's a matter of style.

--Richard

On Dec 13, 2009, at 6:10 PM, Thomson, Martin wrote:

> Personal prejudice against overuse of 2119 language, mostly.
>
> I try not to use 2119 language to describe basic behaviour like
> this. It's overkill. It makes documents seem dictatorial. It's
> also harder to read. It also reduces the impact of 2119 language in
> those places where it is really important.
>
> Imagine if every part of the process describe in this document used
> MUST, starting with the procedure described in Section 2...
>
> --Martin
>
>> -----Original Message-----
>> From: Alissa Cooper [mailto:acooper@cdt.org]
>> Sent: Monday, 14 December 2009 12:43 AM
>> To: Thomson, Martin
>> Cc: geopriv@ietf.org
>> Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-
>> 13.txt
>>
>> Hi Martin,
>>
>> In the new parts about DHCPv4 option 15, can you explain why you
>> don't
>> use 2119 language? In both section 2 and section 3.4 you say that
>> DHCPv4 option 15 "is used" (as opposed to, e.g., "SHOULD be used"),
>> so
>> it sounds like you're stating a fact rather than giving a direction
>> to
>> implementers.
>>
>> Thanks,
>> Alissa
>>
>> On Dec 8, 2009, at 9:21 PM, Thomson, Martin wrote:
>>
>>> In addition to the minor changes suggested on the list, this latest
>>> version addresses comments that came up in the AD review.
>>>
>>> The document is now less negative towards use of DHCPv4 option 15.
>>> Section 4.1 has been moved to Section 3.4 and Section 3 has been
>>> renamed accordingly. There is also a flow chart that should make it
>>> easy for implementers to understand how all the pieces fit together.
>>>
>>> The diff shows the changes:
>>>
>>> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lis-
>> discovery-13.txt
>>>>
>>>
>>> --Martin
>>>
>>>> -----Original Message-----
>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>>>> Behalf Of Internet-Drafts@ietf.org
>>>> Sent: Wednesday, 9 December 2009 12:30 PM
>>>> To: i-d-announce@ietf.org
>>>> Cc: geopriv@ietf.org
>>>> Subject: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-
>> 13.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 : Discovering the Local Location Information
>>>> Server (LIS)
>>>> Author(s) : M. Thomson, J. Winterbottom
>>>> Filename : draft-ietf-geopriv-lis-discovery-13.txt
>>>> Pages : 17
>>>> Date : 2009-12-08
>>>>
>>>> Discovery of the correct Location Information Server (LIS) in the
>>>> local access network is necessary for devices that wish to acquire
>>>> location information from the network. A method is described for
>> the
>>>> discovery of a LIS in the access network serving a device. Dynamic
>>>> Host Configuration Protocol (DHCP) options for IP versions 4 and 6
>>>> are defined that specify a domain name. This domain name is then
>>>> used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
>>>>
>>>> Status of This Memo
>>>>
>>>> This Internet-Draft is submitted to IETF in full conformance with
>> the
>>>> provisions of BCP 78 and BCP 79.
>>>>
>>>> Internet-Drafts are working documents of the Internet Engineering
>>>> Task Force (IETF), its areas, and its working groups. Note that
>>>> other groups may also distribute working documents as Internet-
>>>> Drafts.
>>>>
>>>> Internet-Drafts are draft documents valid for a maximum of six
>> months
>>>> and may be updated, replaced, or obsoleted by other documents at
>>>> any
>>>> time. It is inappropriate to use Internet-Drafts as reference
>>>> material or to cite them other than as "work in progress."
>>>>
>>>> The list of current Internet-Drafts can be accessed at
>>>> http://www.ietf.org/ietf/1id-abstracts.txt.
>>>>
>>>> The list of Internet-Draft Shadow Directories can be accessed at
>>>> http://www.ietf.org/shadow.html.
>>>>
>>>> This Internet-Draft will expire on June 11, 2010.
>>>>
>>>> Copyright Notice
>>>>
>>>> Copyright (c) 2009 IETF Trust and the persons identified as the
>>>> document authors. All rights reserved.
>>>>
>>>> This document is subject to BCP 78 and the IETF Trust's Legal
>>>> Provisions Relating to IETF Documents
>>>> (http://trustee.ietf.org/license-info) in effect on the date of
>>>> publication of this document. Please review these documents
>>>> carefully, as they describe your rights and restrictions with
>> respect
>>>> to this document. Code Components extracted from this document
>>>> must
>>>> include Simplified BSD License text as described in Section 4.e of
>>>> the Trust Legal Provisions and are provided without warranty as
>>>> described in the BSD License.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-
>> discovery-
>>>> 13.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.
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Sunday, December 13, 2009

Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.txt

Personal prejudice against overuse of 2119 language, mostly.

I try not to use 2119 language to describe basic behaviour like this. It's overkill. It makes documents seem dictatorial. It's also harder to read. It also reduces the impact of 2119 language in those places where it is really important.

Imagine if every part of the process describe in this document used MUST, starting with the procedure described in Section 2...

--Martin

> -----Original Message-----
> From: Alissa Cooper [mailto:acooper@cdt.org]
> Sent: Monday, 14 December 2009 12:43 AM
> To: Thomson, Martin
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-
> 13.txt
>
> Hi Martin,
>
> In the new parts about DHCPv4 option 15, can you explain why you don't
> use 2119 language? In both section 2 and section 3.4 you say that
> DHCPv4 option 15 "is used" (as opposed to, e.g., "SHOULD be used"), so
> it sounds like you're stating a fact rather than giving a direction to
> implementers.
>
> Thanks,
> Alissa
>
> On Dec 8, 2009, at 9:21 PM, Thomson, Martin wrote:
>
> > In addition to the minor changes suggested on the list, this latest
> > version addresses comments that came up in the AD review.
> >
> > The document is now less negative towards use of DHCPv4 option 15.
> > Section 4.1 has been moved to Section 3.4 and Section 3 has been
> > renamed accordingly. There is also a flow chart that should make it
> > easy for implementers to understand how all the pieces fit together.
> >
> > The diff shows the changes:
> >
> > <http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lis-
> discovery-13.txt
> > >
> >
> > --Martin
> >
> >> -----Original Message-----
> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> >> Behalf Of Internet-Drafts@ietf.org
> >> Sent: Wednesday, 9 December 2009 12:30 PM
> >> To: i-d-announce@ietf.org
> >> Cc: geopriv@ietf.org
> >> Subject: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-
> 13.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 : Discovering the Local Location Information
> >> Server (LIS)
> >> Author(s) : M. Thomson, J. Winterbottom
> >> Filename : draft-ietf-geopriv-lis-discovery-13.txt
> >> Pages : 17
> >> Date : 2009-12-08
> >>
> >> Discovery of the correct Location Information Server (LIS) in the
> >> local access network is necessary for devices that wish to acquire
> >> location information from the network. A method is described for
> the
> >> discovery of a LIS in the access network serving a device. Dynamic
> >> Host Configuration Protocol (DHCP) options for IP versions 4 and 6
> >> are defined that specify a domain name. This domain name is then
> >> used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
> >>
> >> Status of This Memo
> >>
> >> This Internet-Draft is submitted to IETF in full conformance with
> the
> >> provisions of BCP 78 and BCP 79.
> >>
> >> Internet-Drafts are working documents of the Internet Engineering
> >> Task Force (IETF), its areas, and its working groups. Note that
> >> other groups may also distribute working documents as Internet-
> >> Drafts.
> >>
> >> Internet-Drafts are draft documents valid for a maximum of six
> months
> >> and may be updated, replaced, or obsoleted by other documents at any
> >> time. It is inappropriate to use Internet-Drafts as reference
> >> material or to cite them other than as "work in progress."
> >>
> >> The list of current Internet-Drafts can be accessed at
> >> http://www.ietf.org/ietf/1id-abstracts.txt.
> >>
> >> The list of Internet-Draft Shadow Directories can be accessed at
> >> http://www.ietf.org/shadow.html.
> >>
> >> This Internet-Draft will expire on June 11, 2010.
> >>
> >> Copyright Notice
> >>
> >> Copyright (c) 2009 IETF Trust and the persons identified as the
> >> document authors. All rights reserved.
> >>
> >> This document is subject to BCP 78 and the IETF Trust's Legal
> >> Provisions Relating to IETF Documents
> >> (http://trustee.ietf.org/license-info) in effect on the date of
> >> publication of this document. Please review these documents
> >> carefully, as they describe your rights and restrictions with
> respect
> >> to this document. Code Components extracted from this document must
> >> include Simplified BSD License text as described in Section 4.e of
> >> the Trust Legal Provisions and are provided without warranty as
> >> described in the BSD License.
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-
> discovery-
> >> 13.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.
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.txt

Hi Martin,

In the new parts about DHCPv4 option 15, can you explain why you don't
use 2119 language? In both section 2 and section 3.4 you say that
DHCPv4 option 15 "is used" (as opposed to, e.g., "SHOULD be used"), so
it sounds like you're stating a fact rather than giving a direction to
implementers.

Thanks,
Alissa

On Dec 8, 2009, at 9:21 PM, Thomson, Martin wrote:

> In addition to the minor changes suggested on the list, this latest
> version addresses comments that came up in the AD review.
>
> The document is now less negative towards use of DHCPv4 option 15.
> Section 4.1 has been moved to Section 3.4 and Section 3 has been
> renamed accordingly. There is also a flow chart that should make it
> easy for implementers to understand how all the pieces fit together.
>
> The diff shows the changes:
>
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lis-discovery-13.txt
> >
>
> --Martin
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Internet-Drafts@ietf.org
>> Sent: Wednesday, 9 December 2009 12:30 PM
>> To: i-d-announce@ietf.org
>> Cc: geopriv@ietf.org
>> Subject: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.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 : Discovering the Local Location Information
>> Server (LIS)
>> Author(s) : M. Thomson, J. Winterbottom
>> Filename : draft-ietf-geopriv-lis-discovery-13.txt
>> Pages : 17
>> Date : 2009-12-08
>>
>> Discovery of the correct Location Information Server (LIS) in the
>> local access network is necessary for devices that wish to acquire
>> location information from the network. A method is described for the
>> discovery of a LIS in the access network serving a device. Dynamic
>> Host Configuration Protocol (DHCP) options for IP versions 4 and 6
>> are defined that specify a domain name. This domain name is then
>> used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
>>
>> Status of This Memo
>>
>> This Internet-Draft is submitted to IETF in full conformance with the
>> provisions of BCP 78 and BCP 79.
>>
>> Internet-Drafts are working documents of the Internet Engineering
>> Task Force (IETF), its areas, and its working groups. Note that
>> other groups may also distribute working documents as Internet-
>> Drafts.
>>
>> Internet-Drafts are draft documents valid for a maximum of six months
>> and may be updated, replaced, or obsoleted by other documents at any
>> time. It is inappropriate to use Internet-Drafts as reference
>> material or to cite them other than as "work in progress."
>>
>> The list of current Internet-Drafts can be accessed at
>> http://www.ietf.org/ietf/1id-abstracts.txt.
>>
>> The list of Internet-Draft Shadow Directories can be accessed at
>> http://www.ietf.org/shadow.html.
>>
>> This Internet-Draft will expire on June 11, 2010.
>>
>> Copyright Notice
>>
>> Copyright (c) 2009 IETF Trust and the persons identified as the
>> document authors. All rights reserved.
>>
>> This document is subject to BCP 78 and the IETF Trust's Legal
>> Provisions Relating to IETF Documents
>> (http://trustee.ietf.org/license-info) in effect on the date of
>> publication of this document. Please review these documents
>> carefully, as they describe your rights and restrictions with respect
>> to this document. Code Components extracted from this document must
>> include Simplified BSD License text as described in Section 4.e of
>> the Trust Legal Provisions and are provided without warranty as
>> described in the BSD License.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-
>> 13.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.
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Tuesday, December 8, 2009

[Geopriv] I-D Action:draft-ietf-geopriv-held-identity-extensions-02.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 : Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
Author(s) : J. Winterbottom, et al.
Filename : draft-ietf-geopriv-held-identity-extensions-02.txt
Pages : 29
Date : 2009-12-08

When a Location Information Server receives a request for location
information (using the locationRequest message), described in the
base HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of arriving message as a pointer to the location
determination process. This is sufficient in environments where the
location of a Device can be determined based on its IP address.

Two additional use cases are addresses by this document. In the
first, location configuration requires additional or alternative
identifiers from the source IP address provided in the request. In
the second, an entity other than the Device requests the location of
the Device.

This document extends the HELD protocol to allow the location request
message to carry Device identifiers. Privacy and security
considerations describe the conditions where requests containing
identifiers are permitted.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 12, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-held-identity-extensions-02.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.

Re: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.txt

In addition to the minor changes suggested on the list, this latest version addresses comments that came up in the AD review.

The document is now less negative towards use of DHCPv4 option 15. Section 4.1 has been moved to Section 3.4 and Section 3 has been renamed accordingly. There is also a flow chart that should make it easy for implementers to understand how all the pieces fit together.

The diff shows the changes:

<http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lis-discovery-13.txt>

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Internet-Drafts@ietf.org
> Sent: Wednesday, 9 December 2009 12:30 PM
> To: i-d-announce@ietf.org
> Cc: geopriv@ietf.org
> Subject: [Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.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 : Discovering the Local Location Information
> Server (LIS)
> Author(s) : M. Thomson, J. Winterbottom
> Filename : draft-ietf-geopriv-lis-discovery-13.txt
> Pages : 17
> Date : 2009-12-08
>
> Discovery of the correct Location Information Server (LIS) in the
> local access network is necessary for devices that wish to acquire
> location information from the network. A method is described for the
> discovery of a LIS in the access network serving a device. Dynamic
> Host Configuration Protocol (DHCP) options for IP versions 4 and 6
> are defined that specify a domain name. This domain name is then
> used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
>
> Status of This Memo
>
> This Internet-Draft is submitted to IETF in full conformance with the
> provisions of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on June 11, 2010.
>
> Copyright Notice
>
> Copyright (c) 2009 IETF Trust and the persons identified as the
> document authors. All rights reserved.
>
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document. Please review these documents
> carefully, as they describe your rights and restrictions with respect
> to this document. Code Components extracted from this document must
> include Simplified BSD License text as described in Section 4.e of
> the Trust Legal Provisions and are provided without warranty as
> described in the BSD License.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-
> 13.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.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-lis-discovery-13.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 : Discovering the Local Location Information Server (LIS)
Author(s) : M. Thomson, J. Winterbottom
Filename : draft-ietf-geopriv-lis-discovery-13.txt
Pages : 17
Date : 2009-12-08

Discovery of the correct Location Information Server (LIS) in the
local access network is necessary for devices that wish to acquire
location information from the network. A method is described for the
discovery of a LIS in the access network serving a device. Dynamic
Host Configuration Protocol (DHCP) options for IP versions 4 and 6
are defined that specify a domain name. This domain name is then
used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 11, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-13.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.

Friday, December 4, 2009

[Geopriv] Last Call: draft-ietf-geopriv-geo-uri (A Uniform Resource Identifier for Geographic Locations ('geo' URI)) to Proposed Standard

The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:

- 'A Uniform Resource Identifier for Geographic Locations ('geo' URI) '
<draft-ietf-geopriv-geo-uri-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-12-18. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-geo-uri-04.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18627&rfc_flag=0

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Tuesday, December 1, 2009

Re: [Geopriv] Special session on Indoor Location and Navigation at OGC meeting next week

All -
 
I may have mentioned this before, but the OGC is hosting a special session next Tuesday in Mountain View California on Indoor Location, Navigation, visualization, and sharing Floor Plans. More information can be found here: http://www.ogcnetwork.net/node/624 , Notice that Peter Thornycroft, ARUBA Systems, is presenting.
 
I know this is short notice, but anyone in the Bay area who would like to attend is more then welcome. The special session is open to non-OGC members and is free. Information on the location is here http://www.opengeospatial.org/event/0912tc .
 
If you would like to drop by, please let me know.
 
FYI, CityGML is an OGC standard grounded in the requirements of the AEC and building industries for sharing urban 3d models.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Specification Program
OGC
 
The OGC: Helping the World to Communicate Geographically
 
---------------------
 
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.
 
"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller

Monday, November 30, 2009

[Geopriv] FW: New Version Notification for draft-thomson-geopriv-uncertainty-04

FYI,

This document is part 1 of a new-age self-help series on coping with uncertainty. This part deals with admitting a problem and it provides some home remedies for common ailments.

--Martin

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Tuesday, 1 December 2009 3:51 PM
To: Thomson, Martin
Cc: Winterbottom, James
Subject: New Version Notification for draft-thomson-geopriv-uncertainty-04


A new version of I-D, draft-thomson-geopriv-uncertainty-04.txt has been successfuly submitted by Martin Thomson and posted to the IETF repository.

Filename: draft-thomson-geopriv-uncertainty
Revision: 04
Title: Representation of Uncertainty and Confidence in PIDF-LO
Creation_date: 2009-11-27
WG ID: Independent Submission
Number_of_pages: 38

Abstract:
The key concepts of uncertainty and confidence as they pertain to
location information are defined. Methods for the manipulation of
location estimates that include uncertainty information are outlined.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [Editorial Errata Reported] RFC5491 (1951)

The following errata report has been submitted for RFC5491,
"GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5491&eid=1951

--------------------------------------
Type: Editorial
Reported by: Martin Thomson <martin.thomson@andrew.com>

Section: 5.2.2

Original Text
-------------
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
<gml:pos>43.111 -73.322</gml:pos> <!--F-->
<gml:pos>43.111 -73.222</gml:pos> <!--E-->
<gml:pos>43.311 -73.122</gml:pos> <!--D-->
<gml:pos>43.411 -73.222</gml:pos> <!--C-->
<gml:pos>43.411 -73.322</gml:pos> <!--B-->
<gml:pos>43.311 -73.422</gml:pos> <!--A-->

Corrected Text
--------------
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
<gml:pos>43.111 -73.322</gml:pos> <!--B-->
<gml:pos>43.111 -73.222</gml:pos> <!--C-->
<gml:pos>43.311 -73.122</gml:pos> <!--D-->
<gml:pos>43.411 -73.222</gml:pos> <!--E-->
<gml:pos>43.411 -73.322</gml:pos> <!--F-->
<gml:pos>43.311 -73.422</gml:pos> <!--A-->

Notes
-----
The points in Figure 7 are correct (i.e., they are in a counter-clockwise direction) but the comment labels are in the wrong order.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5491 (draft-ietf-geopriv-pdif-lo-profile-14)
--------------------------------------
Title : GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations
Publication Date : March 2009
Author(s) : J. Winterbottom, M. Thomson, H. Tschofenig
Category : PROPOSED STANDARD
Source : Geographic Location/Privacy
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] FW: New Version Notification for draft-thomson-geopriv-indoor-location-01

FYI,

This draft has been updated with some of the feedback received during the meeting and in private discussions that James and I have had with others.

This is our contribution to the ongoing discussion on indoor locations.

--Martin

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Tuesday, 1 December 2009 3:51 PM
To: Thomson, Martin
Cc: Winterbottom, James
Subject: New Version Notification for draft-thomson-geopriv-indoor-location-01


A new version of I-D, draft-thomson-geopriv-indoor-location-01.txt has been successfuly submitted by Martin Thomson and posted to the IETF repository.

Filename: draft-thomson-geopriv-indoor-location
Revision: 01
Title: Locations with Locally-Defined Coordinate Reference Systems for the Presence Information Data Format - Location Object (PIDF-LO)
Creation_date: 2009-11-30
WG ID: Independent Submission
Number_of_pages: 31

Abstract:
A method is described for constructing a Presence Information Data
Format - Location Object (PIDF-LO) document that contains location
information using a locally-defined coordinate reference system
(CRS). This form of representation allows for use of locally-defined
coordinates with potential advantages for improved accuracy and
usability in local context, in particular location applications that
operate indoors. A framework for defining a local CRS is provided.
A process for transformation of coordinates defined in the local CRS
and the widely used World Geodetic System 1984 (WGS84) CRS is
defined.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Thursday, November 26, 2009

[Geopriv] draft-ietf-geopriv-loc-filters-08 element placement

Regarding the placement of the newly defined XML elements in the filter document.

The new <moved> and <enterOrExit> elements should be a child of the RFC4661 <trigger> element, not a direct child of <filter>. Similarly, the <locationType> element should be a child of the <what> element.

The <filter> element does allow for extension, but the <trigger> element is more appropriate for these additions as they describe events that *trigger* notification. Same goes for locationType.

The examples become...

...in 3.1:

<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:moved>300</lf:moved>
</trigger>
</filter>
</filter-set>

...in 3.4:

<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">

<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>

...and:

<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">

<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
<gml:pos>43.111 -73.322</gml:pos> <!--F-->
<gml:pos>43.111 -73.222</gml:pos> <!--E-->
<gml:pos>43.311 -73.122</gml:pos> <!--D-->
<gml:pos>43.411 -73.222</gml:pos> <!--C-->
<gml:pos>43.411 -73.322</gml:pos> <!--B-->
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>

Section 3.5: The new locationType element belongs in a <what> element:

<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true">
geodetic
</lf:locationType>
</what>
</filter>
</filter-set>

There's also the comment in the schema and some text that might need tweaking, especially in the top of Section 3 regarding a profile of 4661.

And while you're at it; the <?xml version...?> tags aren't necessary; remove 'em.

Apologies for missing this earlier. It's not a big thing, and the doc can probably live without this, but it would be better if this were done correctly.

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Wednesday, November 25, 2009

Re: [Geopriv] Why draft-stanley-geopriv-indoor-location will notinteroperate

Hi Allan,

>...
> Regarding your point about that Civic address elements adding
> information but does not change information.
>
> >> I agree.
>
> However, I can't agree that removing elements is safe.

Removing elements is safe. It has to be. If you create an extension (say pole number or number prefixes) then you must be able to remove the extension, because some implementations wont understand it.

> What happens if you remove the building name from Civic and leave floor
> name. The floor name is not unique without the building name. Therefore
> there is inherent structure in the civic address that must be provided
> if systems need to interoperate using floor names.

Sure, it reduced the usefulness of the location information - it now might be any of a number of different buildings - but it has only increased the region of uncertainty, not moved it.

This might be inadequate for the application in mind, but it hasn't prevented interoperability.

The worst that can happen when an application doesn't support an element is a known ambiguity.

Say someone didn't understand a house number prefix (Brian's new work). Say that element was necessary to distinguish between a-14 and b-14 Smith St. If the application doesn't understand the prefix, it sees HNO=14, which potentially identifies two houses. Now it's uncertain about which house the location refers to, but it hasn't mistakenly picked number 16.

> The Stanley-geopriv-indoor-location uses the same semantics to define a
> fully qualified indoor location where it adds additional parameters to
> the civic address in a structured way to define a position in a floor.
> Without building or floor, the indoor location is meaningless.

But there's a difference between meaningless (or useless) and misleading. Stanley-geopriv-indoor-location allows for the latter.

> So I disagree with your explanation shows that indoor location is not
> compatible with the definition of civic addresses. If you talk to any
> indoor location vendor today they all use a building based reference
> location system (campus->building->floor->etc.) where the position on
> the floor is an extension of the building based model. Many companies
> have done this because it is a "natural" fit.

We disagree. It is certainly not "natural", whatever that means. I can appreciate how it might have been convenient or expedient. Those are often the opposite of correct.

> Again, the Stanley-geopriv-indoor-location proposal does not preclude
> your proposal of using geospatial information for indoor going forward.
> That is one of the fundamental differences between yours and the
> stanley
> draft. And that is why the original recommendation was to continue both
> drafts.

You'll have to explain that. Because I don't see how that might work.

Please, let's try to create one solution for this. Two solutions is an unnecessary burden on implementations.

--Martin

> allan
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Thomson, Martin
> Sent: Tuesday, November 24, 2009 8:50 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Why draft-stanley-geopriv-indoor-location will
> notinteroperate
>
> draft-stanley-geopriv-indoor-location will not interoperate.
>
> I presented the same explanation in response to
> draft-linsner-geopriv-relativeloc; the two proposals are identical in
> this regard, as they are in many other aspects.
>
> --
> Existing civic definitions RFC 4776/5139 follow a simple rule:
>
> The location described by a set of civic address elements is entirely
> contained within the location described by any subset of those
> elements.
>
> Or, from a different angle:
>
> Every civic address element adds information, it does not change
> existing information.
>
> This rule is what makes the civic address definition extensible. This
> rule ensures that elements can be safely ignored by processors that do
> not support them. Applications can even choose to support a subset of
> the civic address elements safely.
>
> For instance, an application that is designed solely for use within
> Austria is able to ignore the STS element. For addresses outside of
> Austria that use STS, the application wont perform well, but at least
> it
> wont break.
>
> It also means that removing elements is safe: it might degrade the
> location but it does not fundamentally change it.
>
> draft-ietf-geopriv-policy relies on this property for its privacy
> transformation. Geocoders rely on this property - they only support a
> subset of the fields. No application can know all possible civic
> address elements (especially if we accept Brian's arbitrary INT
> containers); therefore, all applications necessarily rely on this
> property.
>
> All the extension proposals we've seen so far respect this rule, except
> draft-linsner-geopriv-relativeloc and
> draft-stanley-geopriv-indoor-location. These proposals introduce
> elements that break this cardinal rule. An application that does not
> understand the extension can be mislead if it ignores the offset
> values.
>
> --
> This really only hints at a bigger issue with draft-stanley-... in that
> it incorrectly assumes that this data forms a civic address. Indoor
> location data is a new form of location information, it is not a "small
> expansion of the definition of a civic address". In many respects,
> indoor locations more closely resemble geodetic data.
>
> In any case, it should be clear from my explanation that this extension
> is not compatible with the definition of civic addresses.
>
> --Martin
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv