Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5222

LoST: A Location-to-Service Translation Protocol

Pages: 69
Proposed Standard
Errata
Updated by:  684889179036
Part 3 of 3 – Pages 44 to 69
First   Prev   None

Top   ToC   RFC5222 - Page 44   prevText

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].
Top   ToC   RFC5222 - Page 45
   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>
Top   ToC   RFC5222 - Page 46

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
Top   ToC   RFC5222 - Page 47

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.
Top   ToC   RFC5222 - Page 48
   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)
Top   ToC   RFC5222 - Page 49
   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)
Top   ToC   RFC5222 - Page 50
   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.
Top   ToC   RFC5222 - Page 51

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.
Top   ToC   RFC5222 - Page 52

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>.
Top   ToC   RFC5222 - Page 53
   [25]  Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
         Location-to-Service Translation (LoST) Servers Using the
         Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
         August 2008.
Top   ToC   RFC5222 - Page 54

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">
Top   ToC   RFC5222 - Page 55
               <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>
Top   ToC   RFC5222 - Page 56
       <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"/>
Top   ToC   RFC5222 - Page 57
         </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"/>
Top   ToC   RFC5222 - Page 58
           </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>
Top   ToC   RFC5222 - Page 59
       <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>
Top   ToC   RFC5222 - Page 60
       <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>
Top   ToC   RFC5222 - Page 61
           <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>
Top   ToC   RFC5222 - Page 62
             <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>
Top   ToC   RFC5222 - Page 63
     </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"/>
Top   ToC   RFC5222 - Page 64
         </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>
Top   ToC   RFC5222 - Page 65
     <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>
Top   ToC   RFC5222 - Page 66
       <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>
Top   ToC   RFC5222 - Page 67
           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 21

Appendix B. Examples Online

The XML examples and Relax NG schemas may be found online [24].
Top   ToC   RFC5222 - Page 68

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
Top   ToC   RFC5222 - Page 69
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.