draft-ietf-ecrit-lost-06.txt | draft-ietf-ecrit-lost-07.txt | |||
---|---|---|---|---|
ECRIT T. Hardie | ECRIT T. Hardie | |||
Internet-Draft Qualcomm, Inc. | Internet-Draft Qualcomm, Inc. | |||
Intended status: Standards Track A. Newton | Intended status: Standards Track A. Newton | |||
Expires: February 11, 2008 TranTech, Inc. | Expires: August 10, 2008 American Registry for Internet | |||
Numbers | ||||
H. Schulzrinne | H. Schulzrinne | |||
Columbia University | Columbia University | |||
H. Tschofenig | H. Tschofenig | |||
Nokia Siemens Networks | Nokia Siemens Networks | |||
August 10, 2007 | February 7, 2008 | |||
LoST: A Location-to-Service Translation Protocol | LoST: A Location-to-Service Translation Protocol | |||
draft-ietf-ecrit-lost-06.txt | draft-ietf-ecrit-lost-07.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 40 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on February 11, 2008. | This Internet-Draft will expire on August 8, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
Abstract | Abstract | |||
This document describes an XML-based protocol for mapping service | This document describes an XML-based protocol for mapping service | |||
identifiers and geodetic or civic location information to service | identifiers and geodetic or civic location information to service | |||
contact URIs. In particular, it can be used to determine the | contact URIs. In particular, it can be used to determine the | |||
location-appropriate PSAP for emergency services. | location-appropriate PSAP for emergency services. | |||
Table of Contents | Table of Contents | |||
skipping to change at page 3, line 27 | skipping to change at page 3, line 27 | |||
17.2. Content-type registration for 'application/lost+xml' . . . 51 | 17.2. Content-type registration for 'application/lost+xml' . . . 51 | |||
17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 | 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 | |||
17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 | 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 | |||
17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 | 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 | |||
18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 | 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 | |||
19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 | 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 | |||
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | |||
20.1. Normative References . . . . . . . . . . . . . . . . . . . 58 | 20.1. Normative References . . . . . . . . . . . . . . . . . . . 58 | |||
20.2. Informative References . . . . . . . . . . . . . . . . . . 59 | 20.2. Informative References . . . . . . . . . . . . . . . . . . 59 | |||
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60 | Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 | Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 74 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 75 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 76 | ||||
1. Introduction | 1. Introduction | |||
Protocols such as NAPTR records and the Service Location Protocol | Protocols such as NAPTR records and the Service Location Protocol | |||
(SLP) can be used to discover servers offering a particular service. | (SLP) can be used to discover servers offering a particular service. | |||
However, for an important class of services the appropriate specific | However, for an important class of services the appropriate specific | |||
service instance depends both on the identity of the service and the | service instance depends both on the identity of the service and the | |||
geographic location of the entity that needs to reach it. Emergency | geographic location of the entity that needs to reach it. Emergency | |||
telecommunications services are an important example; here, the | telecommunications services are an important example; here, the | |||
service instance is a Public Safety Answering Point (PSAP) that has | service instance is a Public Safety Answering Point (PSAP) that has | |||
jurisdiction over the location of the user making the call. The | jurisdiction over the location of the user making the call. The | |||
desired PSAP isn't necessarily the one that is topologically or even | desired PSAP isn't necessarily the one that is topologically or even | |||
line-of-sight closest to the caller; rather, it is the one that | line-of-sight closest to the caller; rather, it is the one that | |||
serves the callers location based on jurisdictional boundaries. | serves the caller's location based on jurisdictional boundaries. | |||
This document describes a protocol for mapping a service identifier | This document describes a protocol for mapping a service identifier | |||
(service URNs) [9] and location information compatible with PIDF-LO | and location information compatible with PIDF-LO PIDF-LO [6] to one | |||
[6], namely revised civic location information [10] and a subset of | or more service URIs. Service identifiers take the form of the | |||
the PIDF-LO profile [13] and consequently with the Geo-Shapes [12] | service URNs described in [9]. Location information here includes | |||
defined for GML [11]) to one or more service URLs. Example service | revised civic location information [10] and a subset of the PIDL-LO | |||
URL schemes include sip [14], xmpp [15], and tel [16]. While the | profile [13] which consequently includes the Geo-Shapes [12] defined | |||
initial focus is on providing mapping functions for emergency | for GML [11]. Example service URI schemes include sip [14], xmpp | |||
services, it is likely that the protocol is applicable to other | [15], and tel [16]. While the initial focus is on providing mapping | |||
service URNs. For example, in the United States, the "2-1-1" and | functions for emergency services, it is likely that the protocol is | |||
"3-1-1" service numbers follow a similar location-to-service behavior | applicable to other service URNs. For example, in the United States, | |||
as emergency services. | the "2-1-1" and "3-1-1" service numbers follow a similar location-to- | |||
service behavior as emergency services. | ||||
This document names this protocol "LoST", for Location-to-Service | This document names this protocol "LoST", for Location-to-Service | |||
Translation. LoST Satisfies the requirements [18] for mapping | Translation. LoST Satisfies the requirements [18] for mapping | |||
protocols. LoST provides a number of operations, centered around | protocols. LoST provides a number of operations, centered around | |||
mapping locations and service URNs to service URLs and associated | mapping locations and service URNs to service URLs and associated | |||
information. LoST mapping queries can contain either civic or | information. LoST mapping queries can contain either civic or | |||
geodetic location information. For civic addresses, LoST can | geodetic location information. For civic addresses, LoST can | |||
indicate which parts of the civic address are known to be valid or | indicate which parts of the civic address are known to be valid or | |||
invalid, thus providing address validation, as described in Section | invalid, thus providing address validation, as described in Section | |||
3.5 of [18]. LoST indicates errors in the location data to | 3.5 of [18]. LoST indicates errors in the location data to | |||
skipping to change at page 11, line 8 | skipping to change at page 11, line 8 | |||
'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is | 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is | |||
an indication that the mapping should not be cached. The value of | an indication that the mapping should not be cached. The value of | |||
'NO-EXPIRATION' is an indication that the mapping does not expire. | 'NO-EXPIRATION' is an indication that the mapping does not expire. | |||
On occasion, a server may be forced to return an expired mapping if | On occasion, a server may be forced to return an expired mapping if | |||
it cannot reach the authoritative server or the server fails to | it cannot reach the authoritative server or the server fails to | |||
return a usable answer. Clients and servers MAY cache the mapping so | return a usable answer. Clients and servers MAY cache the mapping so | |||
that they have at least some information available. Caching servers | that they have at least some information available. Caching servers | |||
that have such stale information SHOULD re-attempt the query each | that have such stale information SHOULD re-attempt the query each | |||
time a client requests a mapping. Since the expired mapping will be | time a client requests a mapping. Since the expired mapping will be | |||
returned to the client as a non-error/non-warning response it is the | returned to the client as a non-error/non-warning response ,the | |||
responsibility of the client to check the 'expires' attribute | client MUST check the 'expires' attribute; if the mapping has | |||
associated with mapping data returned in a LoST response to determine | expired, local policy at the client determines whether it discards | |||
whether the mapping is fresh. | the answer and tries again later or uses the possibly stale response. | |||
5.3. Describing the Service with the <displayName> Element | 5.3. Describing the Service with the <displayName> Element | |||
Zero or more <displayName> elements describe the service with a | Zero or more <displayName> elements describe the service with a | |||
string that is suitable for display to human users, each annotated | string that is suitable for display to human users, each annotated | |||
with the 'xml:lang' attribute that contains a language tag to aid in | with the 'xml:lang' attribute that contains a language tag to aid in | |||
the rendering of text. | the rendering of text. | |||
5.4. The Mapped Service: the <service> Element | 5.4. The Mapped Service: the <service> Element | |||
skipping to change at page 14, line 13 | skipping to change at page 14, line 13 | |||
'sips'. | 'sips'. | |||
6. Path of a Request: the <path> Element | 6. Path of a Request: the <path> Element | |||
To prevent loops and to allow tracing of request and response paths, | To prevent loops and to allow tracing of request and response paths, | |||
all requests that allow recursion include a <path> element that | all requests that allow recursion include a <path> element that | |||
contains one or more <via> elements, each possessing an attribute | contains one or more <via> elements, each possessing an attribute | |||
containing a LoST application unique string (see Section 4). The | containing a LoST application unique string (see Section 4). The | |||
order of <via> elements corresponds to the order of LoST servers, | order of <via> elements corresponds to the order of LoST servers, | |||
i.e., the first <via> element identifies the server that initially | i.e., the first <via> element identifies the server that initially | |||
received the request from the client issuing the request. The <via> | received the request from the client issuing the request. Every | |||
element is inserted logically on receipt of the request, so that | server in a recursive query operation is included in the | |||
every server in a recursive query operation is included in the <path> | <path>elelment, including the first server to receive it. | |||
element. | ||||
The server that answers the request instead of forwarding it, such as | The server that answers the request instead of forwarding it, such as | |||
the authoritative server, copies the <path> element verbatim into the | the authoritative server, copies the <path> element verbatim into the | |||
response. The <path> element is not modified in responses as the | response. The <path> element is not modified in responses as the | |||
responses traverses the server chain back to the querying client. | responses traverses the server chain back to the querying client. | |||
If a query is answered iteratively, the querier includes all servers | If a query is answered iteratively, the querier includes all servers | |||
that it has already contacted. | that it has already contacted. | |||
When a cached mapping is returned then the <path> element cached | When a cached mapping is returned then the <path> element cached | |||
skipping to change at page 15, line 15 | skipping to change at page 15, line 15 | |||
7. Identifying the Location Element Used for Mapping: <locationUsed> | 7. Identifying the Location Element Used for Mapping: <locationUsed> | |||
Several of the requests can provide one or more <location> elements, | Several of the requests can provide one or more <location> elements, | |||
among which the server gets to choose. It is useful for the client | among which the server gets to choose. It is useful for the client | |||
to be able to determine which one was actually used in producing the | to be able to determine which one was actually used in producing the | |||
result. For that purpose, the <location> tag MUST contain an 'id' | result. For that purpose, the <location> tag MUST contain an 'id' | |||
attribute that uniquely identifies the <location> element. The | attribute that uniquely identifies the <location> element. The | |||
format of the identifier is left to the client; it could, for | format of the identifier is left to the client; it could, for | |||
example, use a hash of the location information. The server returns | example, use a hash of the location information. The server returns | |||
the identifier for the <location> element it used in the | the identifier for the <location> element it used in the | |||
<locationUsed> tag. | <locationUsed> tag. See Section 8.3.1 for more details. | |||
8. Mapping a Location and Service to URLs: <findService> | 8. Mapping a Location and Service to URLs: <findService> | |||
8.1. Overview | 8.1. Overview | |||
The <findService> query constitutes the core of the LoST | The <findService> query constitutes the core of the LoST | |||
functionality, mapping civic or geodetic locations to URLs and | functionality, mapping civic or geodetic locations to URLs and | |||
associated data. After giving an example, we enumerate the elements | associated data. After giving an example, we enumerate the elements | |||
of the query and response. | of the query and response. | |||
skipping to change at page 19, line 41 | skipping to change at page 19, line 41 | |||
<via source="esgw.ueber-110.de.example"/> | <via source="esgw.ueber-110.de.example"/> | |||
<via source="polizei.muenchen.de.example"/> | <via source="polizei.muenchen.de.example"/> | |||
</path> | </path> | |||
<locationUsed id="627b8bf819d0bad4d"/> | <locationUsed id="627b8bf819d0bad4d"/> | |||
</findServiceResponse> | </findServiceResponse> | |||
Figure 5: A <findServiceResponse> civic address answer | Figure 5: A <findServiceResponse> civic address answer | |||
8.3. Components of the <findService> Request | 8.3. Components of the <findService> Request | |||
The <findService> request includes attributes that govern whether the | The <findService> request includes attributes and elements that | |||
request is handled iteratively or recursively, whether location | govern whether the request is handled iteratively or recursively, | |||
validation is performed and which elements may be contained in the | whether location validation is performed and which elements may be | |||
response. | contained in the response. | |||
8.3.1. The <location> Element | 8.3.1. The <location> Element | |||
The <findService> query communicates location information using one | The <findService> query communicates location information using one | |||
or more <location> elements, which MUST conform to a location profile | or more <location> elements, which MUST conform to a location profile | |||
(see Section 12). There MUST NOT be more than one location element | (see Section 12). There MUST NOT be more than one location element | |||
for each distinct location profile. The order of location elements | for each distinct location profile. The order of location elements | |||
is significant; the server uses the first location element where it | is significant; the server uses the first location element where it | |||
understands the location profile. | understands the location profile. | |||
skipping to change at page 27, line 42 | skipping to change at page 27, line 42 | |||
urn:service:sos.animal-control | urn:service:sos.animal-control | |||
urn:service:sos.fire | urn:service:sos.fire | |||
urn:service:sos.gas | urn:service:sos.gas | |||
urn:service:sos.mountain | urn:service:sos.mountain | |||
urn:service:sos.marine | urn:service:sos.marine | |||
urn:service:sos.physician | urn:service:sos.physician | |||
urn:service:sos.poison | urn:service:sos.poison | |||
urn:service:sos.police | urn:service:sos.police | |||
urn:service:sos.suicide | urn:service:sos.suicide | |||
</serviceList> | </serviceList> | |||
<path> | ||||
<via source="resolver.example"/> | ||||
<via source="authoritative.example"/> | ||||
</path> | ||||
</listServicesResponse> | </listServicesResponse> | |||
Figure 13: Example of <ListServiceResponse> | Figure 13: Example of <ListServiceResponse> | |||
11. List Services By Location: <listServicesByLocation> | 11. List Services By Location: <listServicesByLocation> | |||
A LoST client can ask a LoST server for the list of services it knows | A LoST client can ask a LoST server for the list of services it knows | |||
about for a particular area. The <listServicesByLocation> query | about for a particular area. The <listServicesByLocation> query | |||
contains one or more <location> elements, each from a different | contains one or more <location> elements, each from a different | |||
location profile (Section 12), and may contain the <service> element. | location profile (Section 12), and may contain the <service> element. | |||
skipping to change at page 30, line 15 | skipping to change at page 30, line 15 | |||
12. Location Profiles | 12. Location Profiles | |||
LoST uses location information in <location> elements in requests and | LoST uses location information in <location> elements in requests and | |||
<serviceBoundary> elements in responses. Such location information | <serviceBoundary> elements in responses. Such location information | |||
may be expressed in a variety of ways. This variety can cause | may be expressed in a variety of ways. This variety can cause | |||
interoperability problems where a request or response contains | interoperability problems where a request or response contains | |||
location information in a format not understood by the server or the | location information in a format not understood by the server or the | |||
client, respectively. To achieve interoperability, this document | client, respectively. To achieve interoperability, this document | |||
defines two mandatory-to-implement baseline location profiles to | defines two mandatory-to-implement baseline location profiles to | |||
define the manner in which location information is transmitted. It | define the manner in which location information is transmitted. It | |||
is possible to standardize other profiles in the future. The three | is possible to standardize other profiles in the future. The | |||
baseline profiles are: | baseline profiles are: | |||
geodetic-2d: | geodetic-2d: | |||
a profile for two-dimensional geodetic location information, as | a profile for two-dimensional geodetic location information, as | |||
described in Section 12.2; | described in Section 12.2; | |||
civic: | civic: | |||
a profile consisting of civic address location information, as | a profile consisting of civic address location information, as | |||
skipping to change at page 33, line 12 | skipping to change at page 33, line 12 | |||
This is possible because both Client X and Server Y understand the | This is possible because both Client X and Server Y understand the | |||
baseline profile. | baseline profile. | |||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<findService | <findService | |||
xmlns="urn:ietf:params:xml:ns:lost1" | xmlns="urn:ietf:params:xml:ns:lost1" | |||
xmlns:gml="http://www.opengis.net/gml" | xmlns:gml="http://www.opengis.net/gml" | |||
xmlns:gs="http://www.opengis.net/pidflo/1.0" | xmlns:gs="http://www.opengis.net/pidflo/1.0" | |||
recursive="true" | recursive="true" | |||
serviceBoundary="value"> | serviceBoundary="value"> | |||
<location profile="not-yet-standardized-prism-profile"> | <location id="ABC 123" | |||
profile="not-yet-standardized-prism-profile"> | ||||
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"> | <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"> | |||
<gs:base> | <gs:base> | |||
<gml:Polygon> | <gml:Polygon> | |||
<gml:exterior> | <gml:exterior> | |||
<gml:LinearRing> | <gml:LinearRing> | |||
<gml:posList> | <gml:posList> | |||
42.556844 -73.248157 36.6 | 42.556844 -73.248157 36.6 | |||
42.656844 -73.248157 36.6 | 42.656844 -73.248157 36.6 | |||
42.656844 -73.348157 36.6 | 42.656844 -73.348157 36.6 | |||
42.556844 -73.348157 36.6 | 42.556844 -73.348157 36.6 | |||
skipping to change at page 33, line 34 | skipping to change at page 33, line 35 | |||
</gml:posList> | </gml:posList> | |||
</gml:LinearRing> | </gml:LinearRing> | |||
</gml:exterior> | </gml:exterior> | |||
</gml:Polygon> | </gml:Polygon> | |||
</gs:base> | </gs:base> | |||
<gs:height uom="urn:ogc:def:uom:EPSG::9001"> | <gs:height uom="urn:ogc:def:uom:EPSG::9001"> | |||
2.4 | 2.4 | |||
</gs:height> | </gs:height> | |||
</gs:Prism> | </gs:Prism> | |||
</location> | </location> | |||
<location profile="geodetic-2d"> | <location id="DEF 345" profile="geodetic-2d"> | |||
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> | <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> | |||
<gml:pos>42.656844 -73.348157</gml:pos> | <gml:pos>42.656844 -73.348157</gml:pos> | |||
</gml:Point> | </gml:Point> | |||
</location> | </location> | |||
<service>urn:service:sos.police</service> | <service>urn:service:sos.police</service> | |||
</findService> | </findService> | |||
Figure 16: Example of a <findServices> query with baseline profile | Figure 16: Example of a <findServices> query with baseline profile | |||
interoperability | interoperability | |||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
skipping to change at page 34, line 31 | skipping to change at page 34, line 31 | |||
<p2:pos>37.775 -122.4194</p2:pos> | <p2:pos>37.775 -122.4194</p2:pos> | |||
<p2:pos>37.555 -122.4194</p2:pos> | <p2:pos>37.555 -122.4194</p2:pos> | |||
<p2:pos>37.555 -122.4264</p2:pos> | <p2:pos>37.555 -122.4264</p2:pos> | |||
<p2:pos>37.775 -122.4264</p2:pos> | <p2:pos>37.775 -122.4264</p2:pos> | |||
<p2:pos>37.775 -122.4194</p2:pos> | <p2:pos>37.775 -122.4194</p2:pos> | |||
</p2:LinearRing> | </p2:LinearRing> | |||
</p2:exterior> | </p2:exterior> | |||
</p2:Polygon> | </p2:Polygon> | |||
</serviceBoundary> | </serviceBoundary> | |||
<uri>sip:nypd@example.com</uri> | <uri>sip:nypd@example.com</uri> | |||
<serviceNumber>911</serviceNumber> | ||||
</mapping> | </mapping> | |||
<path> | <path> | |||
<via source="resolver.example"/> | <via source="resolver.example"/> | |||
<via source="authoritative.example"/> | <via source="authoritative.example"/> | |||
</path> | </path> | |||
<locationUsed id="6020688f1ce1896d"/> | <locationUsed id="6020688f1ce1896d"/> | |||
</findServiceResponse> | </findServiceResponse> | |||
Figure 17: Example of a <findServiceResponse> message with baseline | Figure 17: Example of a <findServiceResponse> message with baseline | |||
profile interoperability | profile interoperability | |||
skipping to change at page 42, line 26 | skipping to change at page 42, line 26 | |||
POST method. The HTTP request MUST use the Cache-Control response | POST method. The HTTP request MUST use the Cache-Control response | |||
directive "no-cache" to HTTP-level "caching even by caches that have | directive "no-cache" to HTTP-level "caching even by caches that have | |||
been configured to return stale responses to client requests." | been configured to return stale responses to client requests." | |||
All LoST responses, including those indicating a LoST warning or | All LoST responses, including those indicating a LoST warning or | |||
error, are carried in 2xx responses, typically 200 (OK). Other 2xx | error, are carried in 2xx responses, typically 200 (OK). Other 2xx | |||
responses, in particular 203 (Non-authoritative information) may be | responses, in particular 203 (Non-authoritative information) may be | |||
returned by HTTP caches that disregard the caching instructions. 3xx, | returned by HTTP caches that disregard the caching instructions. 3xx, | |||
4xx and 5xx HTTP response codes indicates that the HTTP request | 4xx and 5xx HTTP response codes indicates that the HTTP request | |||
itself failed or was redirected; these responses do not contain any | itself failed or was redirected; these responses do not contain any | |||
LoST XML elements. | LoST XML elements. The 3xx responses are distinct from the redirects | |||
which are described in Section 13.3; the 13.3 redirects occur after a | ||||
LoST server processes the request. Where an HTTP-layer redirect will | ||||
be general, a LoST server redirect as described in 13.3 might be | ||||
specific to a specific service or be the result of other processing | ||||
by the LoST server. | ||||
The HTTP URL is derived from the LoST server name via U-NAPTR | The HTTP URL is derived from the LoST server name via U-NAPTR | |||
application, as discussed above. | application, as discussed above. | |||
15. Relax NG Schema | 15. Relax NG Schema | |||
This section provides the Relax NG schema used by LoST protocol in | This section provides the Relax NG schema used by LoST protocol in | |||
the compact form. The verbose form is included in Appendix A. | the compact form. The verbose form is included in Appendix A. | |||
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" | namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" | |||
skipping to change at page 43, line 38 | skipping to change at page 43, line 38 | |||
| getServiceBoundaryResponse | | getServiceBoundaryResponse | |||
| errors | | errors | |||
| redirect | | redirect | |||
## | ## | |||
## The queries. | ## The queries. | |||
## | ## | |||
div { | div { | |||
findService = | findService = | |||
element findService { | element findService { | |||
element location { locationInformation }+, | requestLocation, | |||
commonRequestPattern, | commonRequestPattern, | |||
attribute validateLocation { | attribute validateLocation { | |||
xsd:boolean >> a:defaultValue [ "false" ] | xsd:boolean >> a:defaultValue [ "false" ] | |||
}?, | }?, | |||
attribute serviceBoundary { | attribute serviceBoundary { | |||
("reference" | "value") >> a:defaultValue [ "reference" ] | ("reference" | "value") >> a:defaultValue [ "reference" ] | |||
}?, | }?, | |||
attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? | attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? | |||
} | } | |||
listServices = element listServices { commonRequestPattern } | listServices = element listServices { commonRequestPattern } | |||
listServicesByLocation = | listServicesByLocation = | |||
element listServicesByLocation { | element listServicesByLocation { | |||
element location { locationInformation }*, | requestLocation, | |||
commonRequestPattern, | commonRequestPattern, | |||
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? | attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? | |||
} | } | |||
getServiceBoundary = | getServiceBoundary = | |||
element getServiceBoundary { serviceBoundaryKey, extensionPoint } | element getServiceBoundary { serviceBoundaryKey, extensionPoint } | |||
} | } | |||
## | ## | |||
## The responses. | ## The responses. | |||
## | ## | |||
div { | div { | |||
findServiceResponse = | findServiceResponse = | |||
element findServiceResponse { | element findServiceResponse { | |||
mapping+, locationValidation?, commonResponsePattern | mapping+, locationValidation?, commonResponsePattern, locationUsed | |||
} | } | |||
listServicesResponse = | listServicesResponse = | |||
element listServicesResponse { serviceList, commonResponsePattern } | element listServicesResponse { serviceList, commonResponsePattern } | |||
listServicesByLocationResponse = | listServicesByLocationResponse = | |||
element listServicesByLocationResponse { | element listServicesByLocationResponse { | |||
serviceList, commonResponsePattern | serviceList, commonResponsePattern, locationUsed | |||
} | } | |||
getServiceBoundaryResponse = | getServiceBoundaryResponse = | |||
element getServiceBoundaryResponse { | element getServiceBoundaryResponse { | |||
serviceBoundary, commonResponsePattern | serviceBoundary, commonResponsePattern | |||
} | } | |||
} | } | |||
## | ## | |||
## A pattern common to some of the queries. | ## A pattern common to some of the queries. | |||
## | ## | |||
skipping to change at page 44, line 48 | skipping to change at page 44, line 48 | |||
} | } | |||
## | ## | |||
## A pattern common to responses. | ## A pattern common to responses. | |||
## | ## | |||
div { | div { | |||
commonResponsePattern = warnings*, path, extensionPoint | commonResponsePattern = warnings*, path, extensionPoint | |||
} | } | |||
## | ## | |||
## Location in Requests | ||||
## | ||||
div { | ||||
requestLocation = | ||||
element location { | ||||
attribute id { xsd:token }, | ||||
locationInformation | ||||
}+ | ||||
} | ||||
## | ||||
## Location Information | ## Location Information | |||
## | ## | |||
div { | div { | |||
locationInformation = | locationInformation = | |||
extensionPoint+, | extensionPoint+, | |||
attribute profile { xsd:NMTOKEN }? | attribute profile { xsd:NMTOKEN }? | |||
} | } | |||
## | ## | |||
## Service Boundary | ## Service Boundary | |||
skipping to change at page 45, line 39 | skipping to change at page 45, line 50 | |||
## places through which information flowed | ## places through which information flowed | |||
## | ## | |||
div { | div { | |||
path = | path = | |||
element path { | element path { | |||
element via { source, extensionPoint }+ | element via { source, extensionPoint }+ | |||
} | } | |||
} | } | |||
## | ## | |||
## Location Used | ||||
## | ||||
div { | ||||
locationUsed = | ||||
element locationUsed { | ||||
attribute id { xsd:token } | ||||
}? | ||||
} | ||||
## | ||||
## Expires pattern | ## Expires pattern | |||
## | ## | |||
div { | div { | |||
expires = | expires = | |||
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } | attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } | |||
} | } | |||
## | ## | |||
## A QName list | ## A QName list | |||
## | ## | |||
skipping to change at page 46, line 19 | skipping to change at page 46, line 41 | |||
mapping = | mapping = | |||
element mapping { | element mapping { | |||
element displayName { | element displayName { | |||
xsd:string, | xsd:string, | |||
attribute xml:lang { xsd:language } | attribute xml:lang { xsd:language } | |||
}*, | }*, | |||
service, | service, | |||
(serviceBoundary | serviceBoundaryReference)?, | (serviceBoundary | serviceBoundaryReference)?, | |||
element uri { xsd:anyURI }*, | element uri { xsd:anyURI }*, | |||
element serviceNumber { | element serviceNumber { | |||
xsd:string { pattern = "[0-9*#]+" } | xsd:token { pattern = "[0-9*#]+" } | |||
}?, | }?, | |||
extensionPoint, | extensionPoint, | |||
expires, | expires, | |||
attribute lastUpdated { xsd:dateTime }, | attribute lastUpdated { xsd:dateTime }, | |||
source, | source, | |||
attribute sourceId { xsd:token }, | attribute sourceId { xsd:token }, | |||
message | message | |||
} | } | |||
} | } | |||
skipping to change at page 48, line 21 | skipping to change at page 48, line 44 | |||
message, | message, | |||
extensionPoint | extensionPoint | |||
} | } | |||
} | } | |||
## | ## | |||
## Some common patterns. | ## Some common patterns. | |||
## | ## | |||
div { | div { | |||
message = | message = | |||
(attribute message { xsd:string }, | (attribute message { xsd:token }, | |||
attribute xml:lang { xsd:language })? | attribute xml:lang { xsd:language })? | |||
service = element service { xsd:anyURI }? | service = element service { xsd:anyURI }? | |||
appUniqueString = | appUniqueString = | |||
xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } | xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } | |||
source = attribute source { appUniqueString } | source = attribute source { appUniqueString } | |||
serviceList = | serviceList = | |||
element serviceList { | element serviceList { | |||
list { xsd:anyURI* } | list { xsd:anyURI* } | |||
} | } | |||
} | } | |||
## | ## | |||
## Patterns for inclusion of elements from schemas in | ## Patterns for inclusion of elements from schemas in | |||
## other namespaces. | ## other namespaces. | |||
skipping to change at page 53, line 11 | skipping to change at page 53, line 11 | |||
This specification is a work item of the IETF ECRIT working group, | This specification is a work item of the IETF ECRIT working group, | |||
with mailing list address <ecrit@ietf.org>. | with mailing list address <ecrit@ietf.org>. | |||
Change controller: | Change controller: | |||
The IESG <iesg@ietf.org> | The IESG <iesg@ietf.org> | |||
17.3. LoST Relax NG Schema Registration | 17.3. LoST Relax NG Schema Registration | |||
URI: urn:ietf:params:xml:ns:lost1 | URI: urn:ietf:params:xml:schema:lost1 | |||
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | |||
(Hannes.Tschofenig@nsn.com). | (Hannes.Tschofenig@nsn.com). | |||
Relax NG Schema: The Relax NG schema to be registered is contained | Relax NG Schema: The Relax NG schema to be registered is contained | |||
in Section 15. Its first line is | in Section 15. Its first line is | |||
default namespace = "urn:ietf:params:xml:ns:lost1" | default namespace = "urn:ietf:params:xml:ns:lost1" | |||
and its last line is | and its last line is | |||
skipping to change at page 55, line 16 | skipping to change at page 55, line 16 | |||
There are several threats to the overall system of which service | There are several threats to the overall system of which service | |||
mapping forms a part. An attacker that can obtain service contact | mapping forms a part. An attacker that can obtain service contact | |||
URIs can use those URIs to attempt to disrupt those services. An | URIs can use those URIs to attempt to disrupt those services. An | |||
attacker that can prevent the lookup of contact URIs can impair the | attacker that can prevent the lookup of contact URIs can impair the | |||
reachability of such services. An attacker that can eavesdrop on the | reachability of such services. An attacker that can eavesdrop on the | |||
communication requesting this lookup can surmise the existence of an | communication requesting this lookup can surmise the existence of an | |||
emergency and possibly its nature, and may be able to use this to | emergency and possibly its nature, and may be able to use this to | |||
launch a physical attack on the caller. | launch a physical attack on the caller. | |||
To avoid that an attacker can modify the query or its result, the use | To avoid that an attacker can modify the query or its result, TLS | |||
of channel security, such as TLS, is RECOMMENDED. | MUST be implemented and SHOULD be used. Use is RECOMMENDED both for | |||
clients' queries to servers and for queries among servers; this | ||||
latter recommendation is to help avoid cache poisoning attacks by | ||||
replacing answers given to caching servers. The use of server | ||||
identity checks is also RECOMMENDED, as described in [4] | ||||
Generally, authentication and authorization is not required for | Generally, authentication and authorization is not required for | |||
mapping queries. If it is, authentication mechanism of the | mapping queries. If it is, authentication mechanism of the | |||
underlying transport mechanism, such as HTTP basic and digest | underlying transport mechanism, such as HTTP basic and digest | |||
authentication, MAY be used. (Basic authentication SHOULD only be | authentication, MAY be used. (Basic authentication SHOULD only be | |||
used in combination with TLS.) | used in combination with TLS.) | |||
A more detailed description of threats and security requirements are | A more detailed description of threats and security requirements are | |||
provided in [17]. | provided in [17]. | |||
skipping to change at page 58, line 5 | skipping to change at page 57, line 51 | |||
o Wonsang Song | o Wonsang Song | |||
o Jong-Yul Kim | o Jong-Yul Kim | |||
o Anna Makarowska | o Anna Makarowska | |||
o Krzysztof Rzecki | o Krzysztof Rzecki | |||
o Blaszczyk Piotr | o Blaszczyk Piotr | |||
We would like to thank Jon Peterson for his IESG review comments. | ||||
20. References | 20. References | |||
20.1. Normative References | 20.1. Normative References | |||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |||
Considerations Section in RFCs", BCP 26, RFC 2434, | Considerations Section in RFCs", BCP 26, RFC 2434, | |||
October 1998. | October 1998. | |||
skipping to change at page 58, line 35 | skipping to change at page 58, line 35 | |||
[6] Peterson, J., "A Presence-based GEOPRIV Location Object | [6] Peterson, J., "A Presence-based GEOPRIV Location Object | |||
Format", RFC 4119, December 2005. | Format", RFC 4119, December 2005. | |||
[7] Freed, N. and J. Klensin, "Media Type Specifications and | [7] Freed, N. and J. Klensin, "Media Type Specifications and | |||
Registration Procedures", BCP 13, RFC 4288, December 2005. | Registration Procedures", BCP 13, RFC 4288, December 2005. | |||
[8] Daigle, L., "Domain-Based Application Service Location Using | [8] Daigle, L., "Domain-Based Application Service Location Using | |||
URIs and the Dynamic Delegation Discovery Service (DDDS)", | URIs and the Dynamic Delegation Discovery Service (DDDS)", | |||
RFC 4848, April 2007. | RFC 4848, April 2007. | |||
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", | [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency | |||
draft-ietf-ecrit-service-urn-06 (work in progress), March 2007. | and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 | |||
(work in progress), August 2007. | ||||
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format | [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format | |||
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in | for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in | |||
progress), February 2007. | progress), December 2007. | |||
[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, | [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, | |||
"Geographic information - Geography Markup Language (GML)", OGC | "Geographic information - Geography Markup Language (GML)", OGC | |||
Standard OpenGIS 03-105r1, April 2004. | Standard OpenGIS 03-105r1, April 2004. | |||
[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application | [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application | |||
Schema for use by the Internet Engineering Task Force (IETF)", | Schema for use by the Internet Engineering Task Force (IETF)", | |||
Candidate OpenGIS Implementation Specification , December 2006. | Candidate OpenGIS Implementation Specification , December 2006. | |||
20.2. Informative References | 20.2. Informative References | |||
[13] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, | [13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV | |||
Considerations and Recommendations", | PIDF-LO Usage Clarification, Considerations and | |||
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), | Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work | |||
July 2007. | in progress), October 2007. | |||
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., | [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., | |||
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: | Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: | |||
Session Initiation Protocol", RFC 3261, June 2002. | Session Initiation Protocol", RFC 3261, June 2002. | |||
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence | [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence | |||
Protocol (XMPP): Instant Messaging and Presence", RFC 3921, | Protocol (XMPP): Instant Messaging and Presence", RFC 3921, | |||
October 2004. | October 2004. | |||
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, | [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, | |||
December 2004. | December 2004. | |||
[17] Taylor, T., "Security Threats and Requirements for Emergency | [17] Taylor, T., "Security Threats and Requirements for Emergency | |||
Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 | Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 | |||
(work in progress), April 2007. | (work in progress), August 2007. | |||
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency | [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency | |||
Context Resolution with Internet Technologies", | Context Resolution with Internet Technologies", | |||
draft-ietf-ecrit-requirements-13 (work in progress), | draft-ietf-ecrit-requirements-13 (work in progress), | |||
March 2007. | March 2007. | |||
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and | [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and | |||
Framework", draft-ietf-ecrit-mapping-arch-02 (work in | Framework", draft-ietf-ecrit-mapping-arch-03 (work in | |||
progress), July 2007. | progress), September 2007. | |||
[20] Rosen, B. and J. Polk, "Best Current Practice for | [20] Rosen, B. and J. Polk, "Best Current Practice for | |||
Communications Services in support of Emergency Calling", | Communications Services in support of Emergency Calling", | |||
draft-ietf-ecrit-phonebcp-01 (work in progress), March 2007. | draft-ietf-ecrit-phonebcp-03 (work in progress), November 2007. | |||
URIs | ||||
[21] <http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/RelaxNG> | ||||
Appendix A. Non-Normative RELAX NG Schema in XML Syntax | Appendix A. Non-Normative RELAX NG Schema in XML Syntax | |||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<grammar ns="urn:ietf:params:xml:ns:lost1" | <grammar ns="urn:ietf:params:xml:ns:lost1" | |||
xmlns="http://relaxng.org/ns/structure/1.0" | xmlns="http://relaxng.org/ns/structure/1.0" | |||
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" | xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" | |||
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> | datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> | |||
<start> | <start> | |||
skipping to change at page 60, line 42 | skipping to change at page 61, line 42 | |||
</choice> | </choice> | |||
</start> | </start> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
The queries. | The queries. | |||
</a:documentation> | </a:documentation> | |||
<define name="findService"> | <define name="findService"> | |||
<element name="findService"> | <element name="findService"> | |||
<oneOrMore> | <ref name="requestLocation" /> | |||
<element name="location"> | ||||
<ref name="locationInformation" /> | ||||
</element> | ||||
</oneOrMore> | ||||
<ref name="commonRequestPattern" /> | <ref name="commonRequestPattern" /> | |||
<optional> | <optional> | |||
<attribute name="validateLocation"> | <attribute name="validateLocation"> | |||
<data type="boolean" /> | <data type="boolean" /> | |||
<a:defaultValue>false</a:defaultValue> | <a:defaultValue>false</a:defaultValue> | |||
</attribute> | </attribute> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<attribute name="serviceBoundary"> | <attribute name="serviceBoundary"> | |||
<choice> | <choice> | |||
skipping to change at page 61, line 32 | skipping to change at page 62, line 28 | |||
</define> | </define> | |||
<define name="listServices"> | <define name="listServices"> | |||
<element name="listServices"> | <element name="listServices"> | |||
<ref name="commonRequestPattern" /> | <ref name="commonRequestPattern" /> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="listServicesByLocation"> | <define name="listServicesByLocation"> | |||
<element name="listServicesByLocation"> | <element name="listServicesByLocation"> | |||
<zeroOrMore> | <ref name="requestLocation" /> | |||
<element name="location"> | ||||
<ref name="locationInformation" /> | ||||
</element> | ||||
</zeroOrMore> | ||||
<ref name="commonRequestPattern" /> | <ref name="commonRequestPattern" /> | |||
<optional> | <optional> | |||
<attribute name="recursive"> | <attribute name="recursive"> | |||
<data type="boolean" /> | <data type="boolean" /> | |||
<a:defaultValue>true</a:defaultValue> | <a:defaultValue>true</a:defaultValue> | |||
</attribute> | </attribute> | |||
</optional> | </optional> | |||
</element> | </element> | |||
</define> | </define> | |||
skipping to change at page 62, line 12 | skipping to change at page 63, line 4 | |||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
</element> | </element> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
The responses. | The responses. | |||
</a:documentation> | </a:documentation> | |||
<define name="findServiceResponse"> | <define name="findServiceResponse"> | |||
<element name="findServiceResponse"> | <element name="findServiceResponse"> | |||
<oneOrMore> | <oneOrMore> | |||
<ref name="mapping" /> | <ref name="mapping" /> | |||
</oneOrMore> | </oneOrMore> | |||
<optional> | <optional> | |||
<ref name="locationValidation" /> | <ref name="locationValidation" /> | |||
</optional> | </optional> | |||
<ref name="commonResponsePattern" /> | <ref name="commonResponsePattern" /> | |||
<ref name="locationUsed" /> | ||||
</element> | </element> | |||
</define> | </define> | |||
<define name="listServicesResponse"> | <define name="listServicesResponse"> | |||
<element name="listServicesResponse"> | <element name="listServicesResponse"> | |||
<ref name="serviceList" /> | <ref name="serviceList" /> | |||
<ref name="commonResponsePattern" /> | <ref name="commonResponsePattern" /> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="listServicesByLocationResponse"> | <define name="listServicesByLocationResponse"> | |||
<element name="listServicesByLocationResponse"> | <element name="listServicesByLocationResponse"> | |||
<ref name="serviceList" /> | <ref name="serviceList" /> | |||
<ref name="commonResponsePattern" /> | <ref name="commonResponsePattern" /> | |||
<ref name="locationUsed" /> | ||||
</element> | </element> | |||
</define> | </define> | |||
<define name="getServiceBoundaryResponse"> | <define name="getServiceBoundaryResponse"> | |||
<element name="getServiceBoundaryResponse"> | <element name="getServiceBoundaryResponse"> | |||
<ref name="serviceBoundary"/> | <ref name="serviceBoundary"/> | |||
<ref name="commonResponsePattern" /> | <ref name="commonResponsePattern" /> | |||
</element> | </element> | |||
</define> | </define> | |||
skipping to change at page 63, line 33 | skipping to change at page 64, line 25 | |||
<zeroOrMore> | <zeroOrMore> | |||
<ref name="warnings" /> | <ref name="warnings" /> | |||
</zeroOrMore> | </zeroOrMore> | |||
<ref name="path" /> | <ref name="path" /> | |||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Location in Requests | ||||
</a:documentation> | ||||
<define name="requestLocation"> | ||||
<oneOrMore> | ||||
<element name="location"> | ||||
<attribute name="id" > | ||||
<data type="token" /> | ||||
</attribute> | ||||
<ref name="locationInformation" /> | ||||
</element> | ||||
</oneOrMore> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
Location Information | Location Information | |||
</a:documentation> | </a:documentation> | |||
<define name="locationInformation"> | <define name="locationInformation"> | |||
<oneOrMore> | <oneOrMore> | |||
<ref name="extensionPoint"/> | <ref name="extensionPoint"/> | |||
</oneOrMore> | </oneOrMore> | |||
<optional> | <optional> | |||
<attribute name="profile"> | <attribute name="profile"> | |||
<data type="NMTOKEN" /> | <data type="NMTOKEN" /> | |||
skipping to change at page 65, line 8 | skipping to change at page 66, line 18 | |||
<ref name="source" /> | <ref name="source" /> | |||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
</element> | </element> | |||
</oneOrMore> | </oneOrMore> | |||
</element> | </element> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Location Used | ||||
</a:documentation> | ||||
<define name="locationUsed"> | ||||
<optional> | ||||
<element name="locationUsed"> | ||||
<attribute name="id"> | ||||
<data type="token" /> | ||||
</attribute> | ||||
</element> | ||||
</optional> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
Expires pattern | Expires pattern | |||
</a:documentation> | </a:documentation> | |||
<define name="expires"> | <define name="expires"> | |||
<attribute name="expires"> | <attribute name="expires"> | |||
<choice> | <choice> | |||
<data type="dateTime"/> | <data type="dateTime"/> | |||
<value>NO-CACHE</value> | <value>NO-CACHE</value> | |||
<value>NO-EXPIRATION</value> | <value>NO-EXPIRATION</value> | |||
</choice> | </choice> | |||
skipping to change at page 66, line 17 | skipping to change at page 67, line 42 | |||
<ref name="serviceBoundaryReference"/> | <ref name="serviceBoundaryReference"/> | |||
</choice> | </choice> | |||
</optional> | </optional> | |||
<zeroOrMore> | <zeroOrMore> | |||
<element name="uri"> | <element name="uri"> | |||
<data type="anyURI"/> | <data type="anyURI"/> | |||
</element> | </element> | |||
</zeroOrMore> | </zeroOrMore> | |||
<optional> | <optional> | |||
<element name="serviceNumber"> | <element name="serviceNumber"> | |||
<data type="string"> | <data type="token"> | |||
<param name="pattern">[0-9*#]+</param> | <param name="pattern">[0-9*#]+</param> | |||
</data> | </data> | |||
</element> | </element> | |||
</optional> | </optional> | |||
<ref name="extensionPoint"/> | <ref name="extensionPoint"/> | |||
<ref name="expires"/> | <ref name="expires"/> | |||
<attribute name="lastUpdated"> | <attribute name="lastUpdated"> | |||
<data type="dateTime"/> | <data type="dateTime"/> | |||
</attribute> | </attribute> | |||
<ref name="source" /> | <ref name="source" /> | |||
skipping to change at page 67, line 33 | skipping to change at page 69, line 10 | |||
<optional> | <optional> | |||
<ref name="badRequest" /> | <ref name="badRequest" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="internalError" /> | <ref name="internalError" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="serviceSubstitution" /> | <ref name="serviceSubstitution" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="defaultMappingReturned" /> | ||||
</optional> | ||||
<optional> | ||||
<ref name="forbidden" /> | <ref name="forbidden" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="notFound" /> | <ref name="notFound" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="loop" /> | <ref name="loop" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="serviceNotImplemented" /> | <ref name="serviceNotImplemented" /> | |||
skipping to change at page 69, line 4 | skipping to change at page 70, line 30 | |||
<element name="badRequest"> | <element name="badRequest"> | |||
<ref name="basicException"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="internalError"> | <define name="internalError"> | |||
<element name="internalError"> | <element name="internalError"> | |||
<ref name="basicException"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="serviceSubstitution"> | <define name="serviceSubstitution"> | |||
<element name="serviceSubstitution"> | <element name="serviceSubstitution"> | |||
<ref name="basicException"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="defaultMappingReturned"> | ||||
<element name="defaultMappingReturned"> | ||||
<ref name="basicException"/> | ||||
</element> | ||||
</define> | ||||
<define name="forbidden"> | <define name="forbidden"> | |||
<element name="forbidden"> | <element name="forbidden"> | |||
<ref name="basicException"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="notFound"> | <define name="notFound"> | |||
<element name="notFound"> | <element name="notFound"> | |||
<ref name="basicException"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
skipping to change at page 70, line 51 | skipping to change at page 72, line 36 | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Some common patterns. | Some common patterns. | |||
</a:documentation> | </a:documentation> | |||
<define name="message"> | <define name="message"> | |||
<optional> | <optional> | |||
<group> | <group> | |||
<attribute name="message"> | <attribute name="message"> | |||
<data type="string"/> | <data type="token"/> | |||
</attribute> | </attribute> | |||
<attribute name="xml:lang"> | <attribute name="xml:lang"> | |||
<data type="language"/> | <data type="language"/> | |||
</attribute> | </attribute> | |||
</group> | </group> | |||
</optional> | </optional> | |||
</define> | </define> | |||
<define name="service"> | <define name="service"> | |||
<optional> | <optional> | |||
skipping to change at page 71, line 19 | skipping to change at page 73, line 4 | |||
</optional> | </optional> | |||
</define> | </define> | |||
<define name="service"> | <define name="service"> | |||
<optional> | <optional> | |||
<element name="service"> | <element name="service"> | |||
<data type="anyURI"/> | <data type="anyURI"/> | |||
</element> | </element> | |||
</optional> | </optional> | |||
</define> | </define> | |||
<define name="appUniqueString"> | <define name="appUniqueString"> | |||
<data type="string"> | <data type="token"> | |||
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param> | <param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param> | |||
</data> | </data> | |||
</define> | </define> | |||
<define name="source"> | <define name="source"> | |||
<attribute name="source"> | <attribute name="source"> | |||
<ref name="appUniqueString" /> | <ref name="appUniqueString" /> | |||
</attribute> | </attribute> | |||
</define> | </define> | |||
skipping to change at page 73, line 4 | skipping to change at page 74, line 35 | |||
can be added. | can be added. | |||
</a:documentation> | </a:documentation> | |||
<zeroOrMore> | <zeroOrMore> | |||
<ref name="notLost" /> | <ref name="notLost" /> | |||
</zeroOrMore> | </zeroOrMore> | |||
</define> | </define> | |||
</div> | </div> | |||
</grammar> | </grammar> | |||
Figure 25 | Figure 25 | |||
Appendix B. Examples On-line | ||||
The XML examples and Relax NG schemas may be found on-line [21]. | ||||
Authors' Addresses | Authors' Addresses | |||
Ted Hardie | Ted Hardie | |||
Qualcomm, Inc. | Qualcomm, Inc. | |||
Email: hardie@qualcomm.com | Email: hardie@qualcomm.com | |||
Andrew Newton | Andrew Newton | |||
TranTech, Inc. | American Registry for Internet Numbers | |||
4900 Seminary Road, Suite 215 | 3635 Concorde Parkway, Suite 200 | |||
Alexandria, VA 22311 | Chantilly, VA 20151 | |||
US | US | |||
Phone: +1 703 671 9873 | Phone: +1 703 227 9894 | |||
Email: andy@hxr.us | Email: andy@hxr.us | |||
Henning Schulzrinne | Henning Schulzrinne | |||
Columbia University | Columbia University | |||
Department of Computer Science | Department of Computer Science | |||
450 Computer Science Building | 450 Computer Science Building | |||
New York, NY 10027 | New York, NY 10027 | |||
US | US | |||
Phone: +1 212 939 7004 | Phone: +1 212 939 7004 | |||
Email: hgs+ecrit@cs.columbia.edu | Email: hgs+ecrit@cs.columbia.edu | |||
URI: http://www.cs.columbia.edu | URI: http://www.cs.columbia.edu | |||
Hannes Tschofenig | Hannes Tschofenig | |||
Nokia Siemens Networks | Nokia Siemens Networks | |||
Otto-Hahn-Ring 6 | Linnoitustie 6 | |||
Munich, Bavaria 81739 | Espoo 02600 | |||
Germany | Finland | |||
Phone: +49 89 636 40390 | Phone: +358 (50) 4871445 | |||
Email: Hannes.Tschofenig@nsn.com | Email: Hannes.Tschofenig@nsn.com | |||
URI: http://www.tschofenig.com | URI: http://www.tschofenig.com | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
End of changes. 57 change blocks. | ||||
82 lines changed or deleted | 168 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |