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

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 2 Nov 2008 19:55:09 -0500

Thanks, Hannes. I've updated the document based on the text provided,  
but making some minor changes:

- in line with RFC 5222, the requests don't have ...Request in the name;

- the <m> element now can only contain the parameters that are not  
specified in the <getMappings> elements, to avoid needless duplication  
and override conditions;

- allow the "forbidden" error, in case a node tries to update  
something it is not allowed to;

- the deletion mechanism is fleshed out a bit more.

The version that will be submitted tomorrow is at
http://www.cs.columbia.edu/sip/draft/lost-sync/draft-ietf-ecrit-lost-sync-01.html

Last-minute comments would be most helpful.

Henning

On Oct 14, 2008, at 6:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> 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

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit