tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5222

 
 
 

LoST: A Location-to-Service Translation Protocol

Part 3 of 3, p. 44 to 69
Prev RFC Part

 


prevText      Top      Up      ToC       Page 44 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.