TOC 
Network Working GroupB. Rosen
Internet-DraftNeuStar
Intended status: InformationalJuly 03, 2009
Expires: January 4, 2010 


Interior Location in PIDF-LO
draft-rosen-geopriv-pidf-interior-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

RFC5139 defines explicit tags for interior building location such as "BLD" (building), "UNIT", "ROOM". There is wide variation in how interior spaces are named, and the rigid element names provided do not allow accurate representation of interior spaces that don't use the element tags defined. This memo provides an alternative mechanism that provides an extensible flexible way to name spaces in any kind of addressible location.



Table of Contents

1.  Terminology
2.  Introduction
3.  INT element
4.  Civic Address Schema
5.  Examples
6.  Security Considerations
7.  IANA Considerations
    7.1.  XML Schema Registration
    7.2.  CAtype Registry Update
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Author's Address




 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  Introduction

[RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) provides a way to specify an addressable civic location, naming the country, region, city, street name, etc. Within that document is an element FLR (floor) which specifies location within the addressable location. [RFC5139] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” February 2008.) extends the ability to locate interior spaces by defining BLD (Building), UNIT, ROOM, and SEAT. The problem with these elements is that there is very wide variation in how interior spaces are named, and these fixed elements don't allow one to specify interior location that matches signage, drawings or other conventions that are needed to properly locate targets within an addressable location. An example of where the BLD/FLR/UNIT/ROOM doesn't work is an airport. Interior location may be given as Terminal 2, Concourse A, Gate 27.

Additionally, since interior location may vary within a structure (Terminal 2, Food Court, Store 13), and every building could have different conventions, it is essential that a way to parse a sign, drawing, or other representation of interior space to the elements needed to specify that space in a PIDF, or the reverse: creating a human readible string from a PIDF matching signage or drawings, it must be possible to specify how the conversion from human readible to PIDF and vice versa can be accomplished.



 TOC 

3.  INT element

This memo introduces a new CAtype for PIDF-LO called "INT" (for interior) which has two new attributes:

N
The locally significant name of a "level" of interior space. Examples include "Floor", "Concourse" and "Suite".
R
An enumeration of how the name and value are represented in a human readible form.

A PIDF-LO may have multiple INT elements. If there are more than one, the order in which they appear in the PIDF can be signficant.

The R attribute has the following values:

B
The name is expressed before the value as in "Concourse A".
A
The name is expressed after the value as in "Presidential Suite".

If the R subelement is not present, the default value "B" is assumed.

Editor's note: Should FLR, BLD, ROOM, ... be deprecated? I think we should.



 TOC 

4.  Civic Address Schema

TBD



 TOC 

5.  Examples

   <civicAddress xml:lang="en-AU"
     xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
     <country>AU</country>
     <A1>NSW</A1>
     <A3>Wollongong</A3>
     <A4>North Wollongong</A4>
     <RD>Flinders</RD><STS>Street</STS>
     <NAM> Video Rental Store </NAM>
     <PC>2500</PC>
     <INT N='Room' R='A'>Westerns and Classics</INT>
   </civicAddress>

   <civicAddress xml:lang="en-US"
     xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
     <country>US</country>
     <A1>PA</A1>
     <A3>Findlay</A3>
     <RD>Airport</RD><STS>RD</STS>
	<INT N='Terminal'>1</INT>
     <INT N='Concourse'>A</INT>
     <INT N='Gate'>37</INT>
   </civicAddress>


 TOC 

6.  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] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.). Considerations relating to the inclusion of this representation in other XML documents are outside the scope of this document.



 TOC 

7.  IANA Considerations



 TOC 

7.1.  XML Schema Registration

This section replaces the existing XML namespace per the procedures of [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.)

   URI:  urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr

   Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
      Brian Rosen (brian.rosen@neustar.biz).

      The XML for this schema can be found as the entirety of Section 4
      of this document.


 TOC 

7.2.  CAtype Registry Update

This document updates the civic address type registry established by [RFC4776] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” November 2006.). One additional value is added:

    40      INT    Interior Location


 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4119] Peterson, J., “A Presence-based GEOPRIV Location Object Format,” RFC 4119, December 2005 (TXT).
[RFC5139] Thomson, M. and J. Winterbottom, “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO),” RFC 5139, February 2008 (TXT).


 TOC 

8.2. Informative References

[RFC3688] Mealling, M., “The IETF XML Registry,” BCP 81, RFC 3688, January 2004 (TXT).
[RFC4776] Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” RFC 4776, November 2006 (TXT).


 TOC 

Author's Address

  Brian Rosen
  NeuStar, Inc.
  470 Conrad Dr
  Mars, PA 16046
  US
Email:  br@brianrosen.net