[Geopriv] RFC 6447 on Filtering Location Notifications in the Session Initiation Protocol (SIP)

A new Request for Comments is now available in online RFC libraries.

RFC 6447

Title: Filtering Location Notifications in the
Session Initiation Protocol (SIP)
Author: R. Mahy, B. Rosen, H. Tschofenig
Status: Standards Track
Stream: IETF
Date: January 2012
Mailbox: rohan@ekabal.com,
br@brianrosen.net,
Hannes.Tschofenig@gmx.net
Pages: 19
Characters: 36577
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-geopriv-loc-filters-11.txt

URL: http://www.rfc-editor.org/rfc/rfc6447.txt

This document describes filters that limit asynchronous location
notifications to compelling events. These filters are 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). [STANDARDS-TRACK]

This document is a product of the Geographic Location/Privacy Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements. Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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

Re: [Geopriv] LC comment on W3C Geolocation API

Alissa and Richard

Interestingly enough, KML also uses xAL. Google made the KML submission to
the OGC for standards approval. The original Geolocation API to the W3C also
came from Google (different group). Two different address encodings. Hmm.

FYI, I also contributed to the extensions to xAL for handling geodetic
coordinates. xAL now uses GML for such location elements.

Carl

-----Original Message-----
From: Alissa Cooper
Sent: Tuesday, January 03, 2012 7:24 AM
To: GEOPRIV WG
Subject: [Geopriv] LC comment on W3C Geolocation API

Hi all,

The W3C Geolocation API Level 2 is in Last Call until January 15. Richard
and I have put together the comment below to send on behalf of ourselves as
chairs, but we thought we'd run it by the list prior to submitting it in
case any of you have feedback about it. Please let us know this week if you
do.

Thanks,
Alissa

---

Dear Geolocation WG,

Several years ago, there was some discussion on this list about aligning the
address format in the Geolocation spec with the existing civic address
format provided in RFC 5139, or appending an optional object that could
contain an RFC 5139-compatible address when required [1]. As discussed at
the time, one of the advantages of using the RFC 5139 format is that it
accommodates international addresses, whereas there is no obvious mapping
between certain countries' address formats and the format currently used in
the Geolocation spec. China and Japan are the major examples of countries
with "non-Western" address structures, but even for a country as "Western"
as Austria, the mapping may not be straightforward [2].

In the intervening time, there has been some discussion about the alignment
of the Geolocation address format with formats in other specs, namely the
Contacts API [3], although we understand that the decision has been taken
not to align them at this time. The Geolocation format also differs from the
OASIS xAL format [4], which is the basis for at least one existing mobile
addressing API [5].

We would suggest that the Geolocation API not make use of an address format
that differs from existing formats and that does not easily accommodate
addresses from large parts of the world. Concretely, we would ask that the
Geolocation WG consider aligning their format with at least one existing
format (e.g., RFC 5139) or adding an optional object that can capture full
RFC 5139 semantics.

Cheers,
Richard Barnes and Alissa Cooper
IETF GEOPRIV co-chairs

[1] http://lists.w3.org/Archives/Public/public-geolocation/2009Nov/0022.html
[2] http://tools.ietf.org/html/rfc5774
[3] http://lists.w3.org/Archives/Public/public-geolocation/2011May/0014.html
[4] http://www.oasis-open.org/committees/ciq/download.html
[5] http://developer.android.com/reference/android/location/Address.html
_______________________________________________
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] LC comment on W3C Geolocation API

Hi all,

The W3C Geolocation API Level 2 is in Last Call until January 15. Richard and I have put together the comment below to send on behalf of ourselves as chairs, but we thought we'd run it by the list prior to submitting it in case any of you have feedback about it. Please let us know this week if you do.

Thanks,
Alissa

---

Dear Geolocation WG,

Several years ago, there was some discussion on this list about aligning the address format in the Geolocation spec with the existing civic address format provided in RFC 5139, or appending an optional object that could contain an RFC 5139-compatible address when required [1]. As discussed at the time, one of the advantages of using the RFC 5139 format is that it accommodates international addresses, whereas there is no obvious mapping between certain countries' address formats and the format currently used in the Geolocation spec. China and Japan are the major examples of countries with "non-Western" address structures, but even for a country as "Western" as Austria, the mapping may not be straightforward [2].

In the intervening time, there has been some discussion about the alignment of the Geolocation address format with formats in other specs, namely the Contacts API [3], although we understand that the decision has been taken not to align them at this time. The Geolocation format also differs from the OASIS xAL format [4], which is the basis for at least one existing mobile addressing API [5].

We would suggest that the Geolocation API not make use of an address format that differs from existing formats and that does not easily accommodate addresses from large parts of the world. Concretely, we would ask that the Geolocation WG consider aligning their format with at least one existing format (e.g., RFC 5139) or adding an optional object that can capture full RFC 5139 semantics.

Cheers,
Richard Barnes and Alissa Cooper
IETF GEOPRIV co-chairs

[1] http://lists.w3.org/Archives/Public/public-geolocation/2009Nov/0022.html
[2] http://tools.ietf.org/html/rfc5774
[3] http://lists.w3.org/Archives/Public/public-geolocation/2011May/0014.html
[4] http://www.oasis-open.org/committees/ciq/download.html
[5] http://developer.android.com/reference/android/location/Address.html
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv