RFC 5222
LoST: A Location-to-Service Translation Protocol
16. Internationalization Considerations
The LoST protocol is mostly meant for machine-to-machine communications; as such, most of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. The content of the <displayName> element and the 'message' attributes may be displayed to the end user, and they are thus complex types designed for this purpose. LoST exchanges information using XML. All XML processors are required to understand UTF-8 and UTF-16 encodings, and therefore all LoST clients and servers MUST understand UTF-8 and UTF-16 encoded XML. Additionally, LoST servers and clients MUST NOT encode XML with encodings other than UTF-8 or UTF-16.17. IANA Considerations
17.1. U-NAPTR Registrations
This document registers the following U-NAPTR application service tag: Application Service Tag: LoST Defining Publication: The specification contained within this document. This document registers the following U-NAPTR application protocol tags: o Application Protocol Tag: http Defining Publication: RFC 2616 [3] o Application Protocol Tag: https Defining Publication: RFC 2818 [4]17.2. Content-Type Registration for 'application/lost+xml'
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [7] and guidelines in RFC 3023 [5].
MIME media type name: application
MIME subtype name: lost+xml
Mandatory parameters: none
Optional parameters: charset
Indicates the character encoding of enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [5], Section 3.2.
Security considerations: This content type is designed to carry LoST
protocol payloads.
Interoperability considerations: None
Published specification: RFC 5222
Applications that use this media type: Emergency and location-based
systems
Additional information:
Magic Number: None
File Extension: .lostxml
Macintosh file type code: 'TEXT'
Personal and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@nsn.com
Intended usage: LIMITED USE
Author:
This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>.
Change controller:
The IESG <iesg@ietf.org>
17.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:schema:lost1 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com). Relax NG Schema: The Relax NG schema to be registered is contained in Section 15. Its first line is default namespace = "urn:ietf:params:xml:ns:lost1" and its last line is }17.4. LoST Namespace Registration
URI: urn:ietf:params:xml:ns:lost1 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com). XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>LoST Namespace</title> </head> <body> <h1>Namespace for LoST</h1> <h2>urn:ietf:params:xml:ns:lost1</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt"> RFC5222</a>.</p> </body> </html> END
17.5. LoST Location Profile Registry
This document creates a registry of location profile names for the LoST protocol. Profile names are XML tokens. This registry will operate in accordance with RFC 5226 [2], Standards Action. geodetic-2d: Defined in Section 12.2. civic: Defined in Section 12.3.18. Security Considerations
There are several threats to the overall system of which service mapping forms a part. An attacker that can obtain service contact URIs can use those URIs to attempt to disrupt those services. An attacker that can prevent the lookup of contact URIs can impair the reachability of such services. An attacker that can eavesdrop on the communication requesting this lookup can surmise the existence of an emergency and possibly its nature, and may be able to use this to launch a physical attack on the caller. To avoid an attacker modifying the query or its result, Transport Layer Security (TLS) 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 LoST cache poisoning attacks by replacing answers given to caching LoST servers. The use of server identity checks with TLS, as described in Section 3.1 of [4], is also RECOMMENDED. Omitting the server identity check allows an attacker to masquerade as a LoST server, so this approach should be used only when getting any answer, even from a potentially malicious LoST server, is preferred over closing the connection (and thus not getting any answer at all). The host name compared against the server certificate is the host name in the URI, not the DNS name used as input to NAPTR resolution. Note that the security considerations in [22] recommend comparing the input of NAPTR resolution to the certificate, not the output (host name in the URI). This approach was not chosen because in emergency service use cases, it is likely that deployments will see a large number of inputs to the U-NAPTR algorithm resolving to a single server, typically run by a local emergency services authority. In this case, checking the input to the NAPTR resolution against the certificates provided by the LoST server would be impractical, as the list of organizations using it would be large, subject to rapid change, and unknown to the LoST server operator.
The use of server identity does leave open the possibility of DNS- based attacks, as the NAPTR records may be altered by an attacker. The attacks include, for example, interception of DNS packets between the client and the recursive name server, DNS cache poisoning, and intentional modifications by the recursive name server; see [23] for more comprehensive discussion. DNS Security (DNSSEC) [20] can be used to protect against these threats. While DNSSEC is incompletely deployed, users should be aware of the risk, particularly when they are requesting NAPTR records in environments where the local recursive name server, or the network between the client and the local recursive name server, is not considered trustworthy. LoST deployments that are unable to use DNSSEC and unwilling to trust DNS resolution without DNSSEC cannot use the NATPR-based discovery of LoST servers as is. When suitable configuration mechanisms are available, one possibility is to configure the LoST server URIs (instead of the domain name to be used for NAPTR resolution) directly. Future specifications for applying LoST in non-emergency services may also specify additional discovery mechanisms and name matching semantics. Generally, LoST servers will not need to authenticate or authorize clients presenting mapping queries. If they do, an authentication of the underlying transport mechanism, such as HTTP basic and digest authentication, MAY be used. Basic authentication SHOULD only be used in combination with TLS. A more detailed description of threats and security requirements is provided in [17]. The threats and security requirements in non- emergency service uses of LoST may be considerably different from those described here. For example, an attacker might seek monetary benefit by returning service mapping information that directed users to specific service providers. Before deploying LoST in new contexts, a thorough analysis of the threats and requirements specific to that context should be undertaken and decisions made on the appropriate mitigations.19. Acknowledgments
We would like to the thank the following working group members for the detailed review of previous LoST document versions: o Martin Thomson (Review July 2006) o Jonathan Rosenberg (Review July 2006)
o Leslie Daigle (Review September 2006)
o Shida Schubert (Review November 2006)
o Martin Thomson (Review December 2006)
o Barbara Stark (Review January 2007)
o Patrik Faltstrom (Review January 2007)
o Shida Schubert (Review January 2007 as a designated expert
reviewer)
o Jonathan Rosenberg (Review February 2007)
o Tom Taylor (Review February 2007)
o Theresa Reese (Review February 2007)
o Shida Schubert (Review February 2007)
o James Winterbottom (Review July 2007)
o Karl Heinz Wolf (Review May and June 2007)
We would also like to thank the following working group members for
their input to selected design aspects of the LoST protocol:
o Leslie Daigle and Martin Thomson (DNS-based LoST discovery
procedure)
o John Schnizlein (authoritive LoST answers)
o Rohan Mahy (display names)
o James Polk (error handling)
o Ron Watro and Richard Barnes (expiry of cached data)
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James
Winterbottom (indication of PSAP confidence level)
o Martin Thomson (service boundary references)
o Martin Thomson (service URN in LoST response message)
o Clive D.W. Feather, Martin Thomson (validation functionality)
o Roger Marshall (PSAP preference in LoST response)
o James Winterbottom, Marc Linsner, Keith Drage, Tom Taylor, Martin
Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather,
Richard Stastny, John Hearty, Roger Marshall, Jean-Francois Mule,
Pierre Desjardins (location profiles)
o Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson,
Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list
services functionality)
o Martin Thomson, Michael Hammer (mapping of services)
o Shida Schubert, James Winterbottom, Keith Drage (default service
URN)
o Otmar Lendl (LoST aggregation)
o Tom Taylor (terminology)
Klaus Darilion and Marc Linsner provided miscellaneous input to the
design of the protocol. Finally, we would like to thank Brian Rosen,
who participated in almost every discussion thread.
Early implementation efforts led to good feedback by two open source
implementation groups. We would like to thank the implementers for
their work and for helping us to improve the quality of the
specification:
o Wonsang Song
o Jong-Yul Kim
o Anna Makarowska
o Krzysztof Rzecki
o Blaszczyk Piotr
We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault,
and Tim Polk for their IESG review comments. Blocking IESG comments
were also received from Pasi Eronen (succeeding Sam Hartman's review)
and Cullen Jennings. Adjustments have been made to several pieces of
text to satisfy these requests for changes, most notably in the
Security Considerations and in the discussion of redirection in the
presence of overlapping coverage areas.
20. References
20.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [8] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007. [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OGC Standard OpenGIS 03-105r1, April 2004. [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification , December 2006.
20.2. Informative References
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Work in Progress, February 2008. [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [17] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", Work in Progress, September 2007. [20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [21] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, February 2008. [22] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. [23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ RelaxNG>.
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?> <grammar ns="urn:ietf:params:xml:ns:lost1" xmlns="http://relaxng.org/ns/structure/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <start> <a:documentation> Location-to-Service Translation (LoST) Protocol A LoST XML instance has three request types, each with a corresponding response type: find service, list services, and get service boundary. </a:documentation> <choice> <ref name="findService"/> <ref name="listServices"/> <ref name="listServicesByLocation"/> <ref name="getServiceBoundary"/> <ref name="findServiceResponse"/> <ref name="listServicesResponse"/> <ref name="listServicesByLocationResponse"/> <ref name="getServiceBoundaryResponse"/> <ref name="errors"/> <ref name="redirect"/> </choice> </start> <div> <a:documentation> The queries. </a:documentation> <define name="findService"> <element name="findService"> <ref name="requestLocation"/> <ref name="commonRequestPattern"/> <optional> <attribute name="validateLocation"> <data type="boolean"/> <a:defaultValue>false</a:defaultValue> </attribute> </optional> <optional> <attribute name="serviceBoundary">
<choice>
<value>reference</value>
<value>value</value>
</choice>
<a:defaultValue>reference</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="listServices">
<element name="listServices">
<ref name="commonRequestPattern"/>
</element>
</define>
<define name="listServicesByLocation">
<element name="listServicesByLocation">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="getServiceBoundary">
<element name="getServiceBoundary">
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
The responses.
</a:documentation>
<define name="findServiceResponse">
<element name="findServiceResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<optional>
<ref name="locationValidation"/>
</optional>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="listServicesResponse">
<element name="listServicesResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
</element>
</define>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse">
<ref name="serviceBoundary"/>
<ref name="commonResponsePattern"/>
</element>
</define>
</div>
<div>
<a:documentation>
A pattern common to some of the queries.
</a:documentation>
<define name="commonRequestPattern">
<ref name="service"/>
<optional>
<ref name="path"/>
</optional>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<a:documentation>
A pattern common to responses.
</a:documentation>
<define name="commonResponsePattern">
<zeroOrMore>
<ref name="warnings"/>
</zeroOrMore>
<ref name="path"/>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<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
</a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
<attribute name="profile">
<data type="NMTOKEN"/>
</attribute>
</optional>
</define>
</div>
<div>
<a:documentation>
Service Boundary
</a:documentation>
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation"/>
</element>
</oneOrMore>
</define>
</div>
<div>
<a:documentation>
Service Boundary Reference
</a:documentation>
<define name="serviceBoundaryReference">
<element name="serviceBoundaryReference">
<ref name="source"/>
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
<define name="serviceBoundaryKey">
<attribute name="key">
<data type="token"/>
</attribute>
</define>
</div>
<div>
<a:documentation>
Path -
Contains a list of via elements -
places through which information flowed
</a:documentation>
<define name="path">
<element name="path">
<oneOrMore>
<element name="via">
<ref name="source"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</element>
</define>
</div>
<div>
<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
</a:documentation>
<define name="expires">
<attribute name="expires">
<choice>
<data type="dateTime"/>
<value>NO-CACHE</value>
<value>NO-EXPIRATION</value>
</choice>
</attribute>
</define>
</div>
<div>
<a:documentation>
A QName list
</a:documentation>
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<div>
<a:documentation>
A location-to-service mapping.
</a:documentation>
<define name="mapping">
<element name="mapping">
<zeroOrMore>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</zeroOrMore>
<ref name="service"/>
<optional>
<choice>
<ref name="serviceBoundary"/>
<ref name="serviceBoundaryReference"/>
</choice>
</optional>
<zeroOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="serviceNumber">
<data type="token">
<param name="pattern">[0-9*#]+</param>
</data>
</element>
</optional>
<ref name="extensionPoint"/>
<ref name="expires"/>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="source"/>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<ref name="message"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location validation
</a:documentation>
<define name="locationValidation">
<element name="locationValidation">
<optional>
<element name="valid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="invalid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="unchecked">
<ref name="qnameList"/>
</element>
</optional>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
Errors and Warnings Container.
</a:documentation>
<define name="exceptionContainer">
<interleave>
<optional>
<ref name="badRequest"/>
</optional>
<optional>
<ref name="internalError"/>
</optional>
<optional>
<ref name="serviceSubstitution"/>
</optional>
<optional>
<ref name="defaultMappingReturned"/>
</optional>
<optional>
<ref name="forbidden"/>
</optional>
<optional>
<ref name="notFound"/>
</optional>
<optional>
<ref name="loop"/>
</optional>
<optional>
<ref name="serviceNotImplemented"/>
</optional>
<optional>
<ref name="serverTimeout"/>
</optional>
<optional>
<ref name="serverError"/>
</optional>
<optional>
<ref name="locationInvalid"/>
</optional>
<optional>
<ref name="locationProfileUnrecognized"/>
</optional>
</interleave>
<ref name="extensionPoint"/>
<ref name="source"/>
</define>
<define name="errors">
<element name="errors">
<ref name="exceptionContainer"/>
</element>
</define>
<define name="warnings">
<element name="warnings">
<ref name="exceptionContainer"/>
</element>
</define>
</div>
<div>
<a:documentation>
Basic Exceptions
</a:documentation>
<define name="basicException">
<a:documentation>
Exception pattern.
</a:documentation>
<ref name="message"/>
<ref name="extensionPoint"/>
</define>
<define name="badRequest">
<element name="badRequest">
<ref name="basicException"/>
</element>
</define>
<define name="internalError">
<element name="internalError">
<ref name="basicException"/>
</element>
</define>
<define name="serviceSubstitution">
<element name="serviceSubstitution">
<ref name="basicException"/>
</element>
</define>
<define name="defaultMappingReturned">
<element name="defaultMappingReturned">
<ref name="basicException"/>
</element>
</define>
<define name="forbidden">
<element name="forbidden">
<ref name="basicException"/>
</element>
</define>
<define name="notFound">
<element name="notFound">
<ref name="basicException"/>
</element>
</define>
<define name="loop">
<element name="loop">
<ref name="basicException"/>
</element>
</define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="basicException"/>
</element>
</define>
<define name="serverTimeout">
<element name="serverTimeout">
<ref name="basicException"/>
</element>
</define>
<define name="serverError">
<element name="serverError">
<ref name="basicException"/>
</element>
</define>
<define name="locationInvalid">
<element name="locationInvalid">
<ref name="basicException"/>
</element>
</define>
<define name="locationValidationUnavailable">
<element name="locationValidationUnavailable">
<ref name="basicException"/>
</element>
</define>
<define name="locationProfileUnrecognized">
<element name="locationProfileUnrecognized">
<attribute name="unsupportedProfiles">
<data type="NMTOKENS"/>
</attribute>
<ref name="basicException"/>
</element>
</define>
</div>
<div>
<a:documentation>
Redirect.
</a:documentation>
<define name="redirect">
<a:documentation>
Redirect pattern
</a:documentation>
<element name="redirect">
<attribute name="target">
<ref name="appUniqueString"/>
</attribute>
<ref name="source"/>
<ref name="message"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
Some common patterns.
</a:documentation>
<define name="message">
<optional>
<group>
<attribute name="message">
<data type="token"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</group>
</optional>
</define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="appUniqueString">
<data type="token">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data>
</define>
<define name="source">
<attribute name="source">
<ref name="appUniqueString"/>
</attribute>
</define>
<define name="serviceList">
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI"/>
</zeroOrMore>
</list>
</element>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="notLost">
<a:documentation>
Any element not in the LoST namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost1"/>
<nsName/>
</except>
</anyName>
<ref name="anyElement"/>
</element>
</define>
<define name="anyElement">
<a:documentation>
A wildcard pattern for including any element from any other namespace. </a:documentation> <zeroOrMore> <choice> <element> <anyName/> <ref name="anyElement"/> </element> <attribute> <anyName/> </attribute> <text/> </choice> </zeroOrMore> </define> <define name="extensionPoint"> <a:documentation> A point where future extensions (elements from other namespaces) can be added. </a:documentation> <zeroOrMore> <ref name="notLost"/> </zeroOrMore> </define> </div> </grammar> Figure 21Appendix B. Examples Online
The XML examples and Relax NG schemas may be found online [24].
Authors' Addresses
Ted Hardie Qualcomm, Inc. EMail: hardie@qualcomm.com Andrew Newton American Registry for Internet Numbers 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151 US Phone: +1 703 227 9894 EMail: andy@hxr.us Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.