Subject: [Ecrit] draft-ietf-ecrit-lost-sync-00.txt: Text Proposal

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 13:16:59 +0300

I crafted an initial proposal for the text in the draft. 

----------------

3.  Distributing Mappings via <pushMappingsRequest> and
<pushMappingsResponse>

   When a LoST node obtains new information that is of interest to its
   peers, it pushes the new mappings to its peers.  This information
   might arrive through non-LoST means, such as a manual addition to the
   local mappings database, or through another LoST node, via a
   <pushMappings> request or a <getMappingsResponse> described later.

   Each peer keeps track of which peer it has exchanged which mapping
   elements with.  Mapping elements are identified, as described in 
   Section 5.1 of RFC 5222, by the 'source', 'sourceID' and 
   'lastUpdated' parameters.  A mapping is considered the
   same if these three attributes match.  Nodes never push the same
   information to the same peer twice.

   To delete a mapping, the content of the mapping is left empty.  The
   node can delete the mapping from its internal mapping database, but
   has to remember which peers it has distributed this update to. 

   Processing a <pushMappingsRequest> message may lead to a successful
   response in the form of a <pushMappingsResponse> or in an <error> 
   message to be returned.  Only
   the following errors defined in RFC 5222 are re-used: 

    - badRequest
    - internalError
    - serverTimeout

   Neither the <redirect> nor the <warnings> messages are utilized 
   by this specification. 

   The semantic of these errors is described in Section 13.1 of RFC
5222.

   If the set of nodes that are synchronizing their data does not form a
   tree, it is possible that the same information arrives through
   several other nodes.  This is unavoidable, but generally only imposes
   a modest overhead.  (It would be possible to create a spanning tree
   in the same fashion as IP multicast, but the complexity does not seem
   warranted, giving the relatively low volume of data.)

   A newly received mapping M' replaces an existing one M* if the
following 
   conditions hold:
   (1) M'.source equals M*.source (case insensitive comparison)
   (2) M'.sourceID' equals M*.sourceID (case insensitive comparison)
   (3) M'.lastUpdated greater than M*.lastUpdated

   Consider the following example shown in Figure 1. Image a LoST node
that 
   obtained two new mappings identified as follows: 

   * source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
     lastUpdated="2008-11-26T01:00:00Z"
   * source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111" 
     lastUpdated="2008-11-01T01:00:00Z"

   These two mappings have to be added to the peer's mapping database. 

   Additionally, it determines that the following mapping has to be
deleted:

   * source="nj.us.example" sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"

   Figure 1 shows the corresponding <pushMappingsRequest> message: 

<?xml version="1.0" encoding="UTF-8"?>
<sync:pushMappingsRequest xmlns:sync="urn:ietf:params:xml:ns:lost-sync1"
    xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml">

    <sync:mappings>

        <mapping source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
            lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
            <displayName xml:lang="en"> Leonia Police Department
</displayName>
            <service>urn:service:sos.police</service>
            <serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
                <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
                    <country>US</country>
                    <A1>NJ</A1>
                    <A3>Leonia</A3>
                    <PC>07605</PC>
                </civicAddress>
            </serviceBoundary>
            <uri>sip:[email-masked]</uri>
            <serviceNumber>911</serviceNumber>
        </mapping>

        <mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
            source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111">
            <displayName xml:lang="en"> New York City Police Department
</displayName>
            <service>urn:service:sos.police</service>
            <serviceBoundary profile="geodetic-2d">
                <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
                    <p2:exterior>
                        <p2:LinearRing>
                            <p2:pos>37.775 -122.4194</p2:pos>
                            <p2:pos>37.555 -122.4194</p2:pos>
                            <p2:pos>37.555 -122.4264</p2:pos>
                            <p2:pos>37.775 -122.4264</p2:pos>
                            <p2:pos>37.775 -122.4194</p2:pos>
                        </p2:LinearRing>
                    </p2:exterior>
                </p2:Polygon>
            </serviceBoundary>
            <uri>sip:[email-masked]</uri>
            <uri>xmpp:[email-masked]</uri>
            <serviceNumber>911</serviceNumber>
        </mapping>

        <mapping source="nj.us.example" sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
            expires="2008-11-01T01:00:00Z"/>
    </sync:mappings>

</sync:pushMappingsRequest>

                               Figure 1: pushMappingsRequest Example

In response the peer performs the necessary operation and updates its
mapping database.
In particular, it will check whether the fields are understood and
contain values that 
are understood. In our case a positive response is returned as shown in
Figure 2: 

<?xml version="1.0" encoding="UTF-8"?>
<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lost-sync1"/> 

                              Figure 2: pushMappingsResponse Example

4. Requesting Mappings via <getMappingsRequest> and
<getMappingsResponse>

   Instead of pushing mappings to another LoST node a LoST client can
   get list of mappings identified by <m> elements. When a server 
   does not return a mapping as requested then there may be two reasons 
   for this: 

   1) the mapping is not available at that server

   2) the client has the current mapping and hence it does not need to
be 
   resent. 

   A LoST node wanting to synchronize its mapping store
   with another node issues a <getMappingsRequest>, containing an
   enumeration of the current mapping sources, source identifiers and
   lastUpdated in the <m> elements.  The recipient of the request
compares that
   list to its own list of mappings.  It then returns an unordered set
   of mappings that are more recent than the ones identified in the
   <getMappingsRequest>.  

   The querier can limit the scope of the returned mappings returned by
using
   the 'source', 'sourceId', and 'lastUpdated' attributes.  
   If the 'source' attribute is specified, only
   mappings with that particular source attribute are considered.
   Similarly, the 'sourceId' attribute restricts mappings to those
   matching the attribute.  If 'sourceId' is specified, the 'source'
   attribute also needs to be provided, since the 'sourceId' attribute
   is only defined for a particular source.  Similarly, if 'lastUpdated'
   is specified, 'source' and 'sourceId' need to be specified as well.
   In other words, a querier cannot ask for all mappings last updated
   today regardless of source, for example. While the 'source' and the
   'sourceId' attributes are checked for (case insensitive) equality 
   the value in the 'lastUpdated' attribute is compared with the
matching 
   mappings and if a fresher mapping exists then it is returned. 
   <m> elements that do not match any of the locally available mappings 
   in the database are silently ignored. 

   Processing a <getMappingsRequest> message may lead to a successful
   response in the form of a <getMappingsResponse> or in an <error> 
   message to be returned.  Only
   the following errors defined in RFC 5222 are re-used: 

    - badRequest
    - internalError
    - serverTimeout

   Neither the <redirect> nor the <warnings> messages are utilized 
   by this specification. 

   The following example illustrates the usage of the
<getMappingsRequest> 
   and <getMappingsResponse> messages. Figure 3 shows a LoST node 
   requesting a specific mapping for source="authoritative.bar.example"
and
   sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher than 
   "2006-11-01T01:00:00Z". Additionally, all mappings that match 
   source="authoritative.foo.example" are requested. 

<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lost-sync1">
    <m source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
        lastUpdated="2006-11-01T01:00:00Z"/>
    <m source="authoritative.foo.example"/>
</getMappingsRequest>

Figure 3: <getMappingsRequest> Example

The response is shown in Figure 4. A more recent mapping was available
with the
identification of source="authoritative.bar.example" and 
sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that 
matched source="authoritative.foo.example" was found and returned. 

<?xml version="1.0" encoding="UTF-8"?>
<sync:getMappingsResponse xmlns:sync="urn:ietf:params:xml:ns:lost-sync1"
    xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml">

    <sync:mappings>

        <mapping source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
            lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
            <displayName xml:lang="en"> Leonia Police Department
</displayName>
            <service>urn:service:sos.police</service>
            <serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
                <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
                    <country>US</country>
                    <A1>NJ</A1>
                    <A3>Leonia</A3>
                    <PC>07605</PC>
                </civicAddress>
            </serviceBoundary>
            <uri>sip:[email-masked]</uri>
            <serviceNumber>911</serviceNumber>
        </mapping>

        <mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
            source="authoritative.foo.example"
sourceId="7e3f40b098c711dbb606011111111111">
            <displayName xml:lang="en"> New York City Police Department
</displayName>
            <service>urn:service:sos.police</service>
            <serviceBoundary profile="geodetic-2d">
                <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
                    <p2:exterior>
                        <p2:LinearRing>
                            <p2:pos>37.775 -122.4194</p2:pos>
                            <p2:pos>37.555 -122.4194</p2:pos>
                            <p2:pos>37.555 -122.4264</p2:pos>
                            <p2:pos>37.775 -122.4264</p2:pos>
                            <p2:pos>37.775 -122.4194</p2:pos>
                        </p2:LinearRing>
                    </p2:exterior>
                </p2:Polygon>
            </serviceBoundary>
            <uri>sip:[email-masked]</uri>
            <uri>xmpp:[email-masked]</uri>
            <serviceNumber>911</serviceNumber>
        </mapping>

    </sync:mappings>

</sync:getMappingsResponse>

Figure 4: <getMappingsResponse> Example

5. Relax NG Schema

<?xml version="1.0" encoding="utf-8"?>
	
<grammar ns="urn:ietf:params:xml:ns:lost-sync1"
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">

    <include href="lost.rng"/>

    <start combine="choice">

        <a:documentation> Location-to-Service Translation (LoST)
Synchronization Protocol </a:documentation>

        <choice>
            <ref name="pushMappingsRequest"/>
            <ref name="pushMappingsResponse"/>
            <ref name="getMappingsRequest"/>
            <ref name="getMappingsResponse"/>
        </choice>
    </start>

    <define name="pushMappingsRequest">
        <element name="pushMappingsRequest">
            <element name="mappings">
                <oneOrMore>
                    <ref name="mapping"/>
                </oneOrMore>
            </element>

            <ref name="extensionPoint"/>
        </element>
    </define>

    <define name="pushMappingsResponse">
        <element name="pushMappingsResponse">
            <ref name="extensionPoint"/>
        </element>
    </define>

    <define name="getMappingsRequest">
        <element name="getMappingsRequest">
            <oneOrMore>
                <element name="m">
                    <choice>
                        <ref name="ScopeSource"/>
                        <ref name="ScopeSourceId"/>
                        <ref name="ScopeLastUpdated"/>
                    </choice>
                </element>
            </oneOrMore>
            <ref name="extensionPoint"/>
        </element>
    </define>

    <define name="getMappingsResponse">
        <element name="getMappingsResponse">

            <element name="mappings">
                <oneOrMore>
                    <ref name="mapping"/>
                </oneOrMore>
            </element>

            <ref name="extensionPoint"/>

        </element>
    </define>

    <define name="ScopeSource">
        <attribute name="source">
            <data type="token"/>
        </attribute>
    </define>

    <define name="ScopeSourceId">
        <attribute name="source">
            <data type="token"/>
        </attribute>
        <attribute name="sourceId">
            <data type="token"/>
        </attribute>
    </define>

    <define name="ScopeLastUpdated">
        <attribute name="source">
            <data type="token"/>
        </attribute>
        <attribute name="sourceId">
            <data type="token"/>
        </attribute>
        <attribute name="lastUpdated">
            <data type="dateTime"/>
        </attribute>
    </define>

</grammar>

6.  Security Considerations

   The LoST security considerations are discussed in [2].  The
   operations described in this document involve mutually-trusting LoST
   nodes.  These nodes need to authenticate each other.
   Nodes implementing LoST MUST implement mutual authentication 
   based on certificates .

7.  IANA Considerations

No content type registration is needed for this specification. 
The application/lost+xml MIME type is used. 

7.1.  LoST Sync Relax NG Schema Registration

   URI:  urn:ietf:params:xml:ns:lost-sync1

   Registrant Contact:  IETF ECRIT Working Group, Henning Schulzrinne
      ([email-masked]).

   Relax NG Schema:  The Relax NG schema to be registered is contained
      in Section 5.  Its first line is
   
   <?xml version="1.0" encoding="utf-8"?>

   and its last line is

   </grammar>

7.2.  LoST Synchronization Namespace Registration

   URI:  urn:ietf:params:xml:ns:lost-sync1
   Registrant Contact:  IETF ECRIT Working Group, Henning Schulzrinne
      ([email-masked]).
   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 Synchronization Namespace</title>
   </head>
   <body>
     <h1>Namespace for LoST server synchronization</h1>
     <h2>urn:ietf:params:xml:ns:lost-sync1</h2>
   <p>See <a href="[URL of published RFC]">RFCXXXX
       [NOTE TO IANA/RFC-EDITOR:
        Please replace XXXX with the RFC number of this
       specification.]</a>.</p>
   </body>
   </html>
   END
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit