One document matched: draft-tang-spatial-target-00.txt
Internet Engineering Task Force Haitao Tang
INTERNET DRAFT Jose Costa-Requena
draft-tang-spatial-target-00.txt Mari Korkea-Aho
Issued: July 11, 2000 John Loughney
Expires: January 11, 2001 Nokia
Rohan Mahy
Cisco System
Kenji Takahashi
NTT
Stephen Farrell
Baltimore Technologies
Target Naming Scheme
< draft-tang-spatial-target-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. 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.
Conventions Used in This Document
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 RFC-2119.
Abstract
This document proposes a framework and mechanism for target naming.
Target naming is needed for SLoP speakers (SLoP server or client) to
address targets via the SLoP protocol.
Contents
Contents...............................................................1
1 Introduction.........................................................2
1.1 Terminology.......................................................2
2 Naming Targets via Uniform Resource Identifiers......................2
3 Naming Syntax........................................................3
4 Security Considerations..............................................5
5 Acknowledgements.....................................................5
6 Author's Addresses...................................................5
7 References...........................................................6
Internet Draft draft-tang-spatial-target-00.txt July 2000
1 Introduction
The SLoP protocol delivers spatial location information of an object,
called a target. A target is a physical entity in the existing
space/time reference frame or a logical entity that in turn is hosted by
a physical entity in the existing space/time reference frame. A target
may be stationary or in motion.
In order to deal with the spatial location of a target, there must be a
standard method to identify and refer to the target. This document
proposes two identifiers to name a target: (1) Target information ID
(TID) and (2) Target record Accessing iD (TAD).
1.1 Terminology
SLoP _ Spatial Location Protocol
TID - Target information ID
TAD - Target record Accessing iD
2 Naming Targets via Uniform Resource Identifiers
2.1 Usage of TID and TAD
Due to the requirements for target security, roaming, etc., we need to
name a target through two identifiers, i.e., its TID and its TAD.
TID serves as a persistent, location-independent, resource identifier,
valid after the existence of the target. On the other hand, TAD is
generally made of contact information, handling procedure(s), etc., for
the repository of the target's location information.
TAD can only tells you where/how to get the location information of a
given target. There can be more than one TAD for a given TID, which can
be time/place dependent, non-persistent, etc. For example, the TID of
Mike Lee can include information, such as "Name: Mike Lee, Sex: Male,
Nationality: xyz, ID: 221166-3355, etc.".
The TAD of Mike Lee can include information, such as "Identity: a subset
of TID (e.g., his name), Accessing: the contact procedure and address of
his social registration office or the repository having his location
information, etc."
According to real requirements, a TAD may or may not copy certain
information from its associated TID. It is usually an identifier
allocated by/according to the server. In addition, the association
between TID and TAD may or may not be known to other parties. For
example, if no parties (except the target and MAYBE the server) know the
TID-TAD association, anonymity-based services for the target (or its
owner) can be easily realized.
Of the many usages, part or the whole TID is needed to support the
mutual authentication and to set up the association between a target (or
Haitao Tang, et. al. [Page 2]
Internet Draft draft-tang-spatial-target-00.txt July 2000
the owner) and a location server. Though, TAD is the identifier used for
accessing the target's location information at the server by clients of
the server. In addition, a target may be roaming among location servers
over the Internet. Therefore, a target can have various TADs, but only
one (or a few) TID.
2.2 Naming via URI and Its Extension
A Uniform Resource Identifier (URI) [1] is a compact string of
characters for identifying an abstract or physical resource. It is a
very suitable identifier for the targets defined in this document. There
are several well-known subsets of URI, such as, Uniform Resource Name
(URN) [2,3], Uniform Resource Locator (URL), etc. As a subset of URI,
URN is a resource identifier with the specific requirements for enabling
location independent identification of a resource, as well as longevity
of reference. However, the current URI syntax does not tell how to deal
with characters outside of the US-ASCII character set. We thus add a
character-set indicator to the URI based identifiers to tell what
character set is used to code identifiers.
A TID can be easily named with an URN. For example, the URN based TID of
Mike Lee's car can be: "ISO-8859-1:urn:namespace-xyz:car=abc-
888,registration-state=nnn,owner=mike.lee,nationality=xyz,id=221161-
3355,email=mike.lee@hardcom.com,pstn=+358405021988".
The URN based TID of Mike Lee's car can be kept at the car's original
registration repository at state nnn. The URI based TADs of Mike Lee's
car can be depended on where the car is located currently. For example,
when the car is not currently in the country xyz, its TAD can be:
"slop:car=abc-888,registration-state=nnn@car1.find.gov:5888;valid-
till=31.8.2000"
when the car is currently in the country xyz, its TAD can be:
"ISO-8859-1:slop:abc-888@vehicle.monitoring.eu:transport=tcp:2008"
where, "slop"[4] is the protocol or scheme for accessing the location
information of the target.
3 Naming Syntax
The following syntax specification uses ABNF (RFC2234) and the extension
by this document to support various character sets.
TID = structured-tid | unstructured-tid
structured-tid = [character-set ":"] "urn" ":" namespace ":"
1*([key "="] match ",")
; <character-set> is encoded with UTF-8, while the
; others are encoded with the character set
; indicated by character-set, or with the default
; character set UTF-8 if character set is not
; indicated;
; The "," MUST be omitted from the end of
; <structured-tid>
character-set = "UTF-8" | "UTF-16" | "UTF-32" | "ISO-8859-1" |
"ISO-8859-2" | "ISO-8859-5" | "ISO-8859-7" |"GB2312" |
Haitao Tang, et. al. [Page 3]
Internet Draft draft-tang-spatial-target-00.txt July 2000
"Big5"| cset-name
cset-name = 1*(alpha | digit | "-" | ".") ; any UTF-8 coded national
; or international standard
; character-set name
alpha = <any UTF-8 alphabetic character> ; (a-z, A-Z)
digit = <any UTF-8 decimal digit> ; (0-9)
namespace = 1*<any character-set character, excluding reserved>
reserved = ";" | ":" | "=" | "," ; coded according to character-set
key = 1*<any character-set character, excluding reserved>
match = 1*<any character-set character, excluding reserved>
unstructured-tid = [character-set ":"] "uri" ":" namespace ":" NSS
; NSS is defined in RFC2141;
; <character-set> is encoded with UTF-8,
; while the others are encoded with the
; character set indicated by
; character-set, or with the default
; character set UTF-8 if character set is
; not indicated;
TAD = structured-tad | unstructured-tad
structured-tad = [character-set ":"] scheme ":" user-part "@" host
[":" ["transport="] transport-protocol]
[":" port ] [";" 1*([key "="] match ",")]
; <character-set> ":" is encoded with UTF-8,
; while the others are encoded with the
; character set indicated by <character-
; set>, or with the default character set
; UTF-8 if character set is not indicated;
; udp is the default transport protocol if
; not indicated;
; The "," MUST be omitted from the end of
; <structured-tad>
scheme = "slop"
user-part = 1*([user-key "="] user-match ",")
; the "," MUST be omitted from
; the end of <user-part>
user-key = 1*<any character-set character, excluding reserved and "@">
user-match = 1*<any character-set character, excluding reserved and "@">
transport-protocol = "udp" | "tcp" | <any feasible transport protocol>
host = fqdn | ip4-address | ip6-address
port = 1*<any character-set digit> ; (0-9)
fqdn = <any fully qualified domain name>
Haitao Tang, et. al. [Page 4]
Internet Draft draft-tang-spatial-target-00.txt July 2000
ip4-address = <any qualified IPv4 address>
ip6-address = "[" IPv6address "]" ; IPv6address is defined in RFC2373,
; while coded with character-set
unstructured-tad = [character-set ":"] "uri" ":" scheme ":" opaque_part
; opaque_part is defined in RFC2396,
; while its character set is that
; indicated by <character-set>;
; <character-set> ":" is encoded with
; UTF-8, while the others are encoded
; with the character set indicated by
; <character-set>, or with the default
; character set UTF-8 if character set is
; not indicated;
4 Security Considerations
The information in the TID and TAD of a target may need security
protection, decided by the target owner or its server. If so, the owner
and the server SHALL agree and decide who are the allowed parties to
know the information as well as what sort of the information is allowed
to the parties. The parties MUST then be authenticated before their
actual access of the information.
If the owner and the server decide to open the information to the
public, the information is then free for the public access.
5 Acknowledgements
The authors would like to thank James M. Polk, Brian Rosen, La Monte
H.P. Yarroll, Carl Friedberg, and Fritz Hohl for their comments on
target naming issue.
6 Author's Addresses
Haitao Tang
Nokia
P.O. Box 407, FIN-00045 NOKIA GROUP, Finland
Phone: +358 40 7499256
Email: haitao.tang@nokia.com
Jose Costa-Requena
Nokia
Email: Jose.Costa-Requena@nokia.com
Mari Korkea-Aho
Nokia
Email: mari.korkea-aho@nokia.com
John Loughney
Nokia
Email: john.loughney@nokia.com
Rohan Mahy
Cisco System
Email: rohan@cisco.com
Haitao Tang, et. al. [Page 5]
Internet Draft draft-tang-spatial-target-00.txt July 2000
Kenji Takahashi
Information Sharing Platform Laboratories
NTT
3-9-11 Midoricho
Musashino, Tokyo 180-8585 Japan
Phone: +81 422 59 6668
e-mail: kt@nttlabs.com
Stephen Farrell
Baltimore Technologies
61 Fitzwilliam Lane
Dublin 2. Ireland
Phone: +353 1 647 7406
email: stephen.farrell@baltimore.ie
7 References
[1] T. Berners-Lee, R. Fielding, U.C. Irvine, and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax," RFC2396, IETF,
http://www.ietf.org/rfc/rfc2396.txt?number=2396, August 1998.
[2] R. Moats, "URN Syntax," RFC2141, IETF,
ftp://ftp.funet.fi/pub/doc/rfc/rfc2141.txt, May 1997.
[3] L. Daigle, D. van Gulik, R. Iannella, and P. Faltstrom, "URN
Namespace Definition Mechanisms," RFC2611, IETF,
http://www.ietf.org/rfc/rfc2611.txt?number=2611, June 1999.
[4] Brian Rosen, Jose Costa-Requena, Mari Korkea-Aho, Mika Ylianttila,
Rohan Mahy, Kenji Takahashi, and Stephen Farrell, "Spatial Location
Protocol Requirements," draft-ietf-spatial-requirements-00.txt, IETF,
July 2000.
Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Haitao Tang, et. al. [Page 6]| PAFTECH AB 2003-2026 | 2026-04-23 16:40:12 |