< draft-schulzrinne-ecrit-lost-sync-00.txt		draft-schulzrinne-ecrit-lost-sync-01.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia U.		Internet-Draft Columbia U.
	Intended status: Standards Track November 26, 2006		Intended status: Standards Track February 25, 2008
	Expires: May 30, 2007		Expires: August 28, 2008
	Synchronizing Location-to-Service Translation (LoST) Servers		Synchronizing Location-to-Service Translation (LoST) Servers
	draft-schulzrinne-ecrit-lost-sync-00.txt		draft-schulzrinne-ecrit-lost-sync-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 30, 2007.		This Internet-Draft will expire on August 28, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The LoST (Location-to-Service Translation) protocol is used to map		The LoST (Location-to-Service Translation) protocol is used to map
	locations to service URLs. This document defines a set of LoST		locations to service URLs. This document defines a set of LoST
	extensions that allow LoST servers to synchronize their lists of		extensions that allow LoST servers to synchronize their lists of
	mappings.		mappings.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Distributing Mappings via <pushMappingsRequest> . . . . . . . 3		3. Distributing Mappings via <pushMappingsRequest> . . . . . . . 4
	4. Synchronizing Mapping Stores via <getMappingsRequest> and		4. Synchronizing Mapping Stores via <getMappingsRequest> and
	<getMappingsResponse> . . . . . . . . . . . . . . . . . . . . 6		<getMappingsResponse> . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Synchronizing Mapping Stores via <syncMappingsRequest> and
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		<syncMappingsResponse> . . . . . . . . . . . . . . . . . . . . 6
	6.1. LoST Synchronization Namespace Registration . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7.1. LoST Synchronization Namespace Registration . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 9		9. RelaxNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . . 10
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
			Intellectual Property and Copyright Statements . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The LoST (Location-to-Service Translation) protocol [2] maps		The LoST (Location-to-Service Translation) protocol [2] maps
	geographic locations to service URLs. As specified in the LoST		geographic locations to service URLs. As specified in the LoST
	architecture description [3], there are a variety of LoST servers		architecture description [3], there are a variety of LoST servers
	that cooperate to provide a global, scalable and resilient mapping		that cooperate to provide a global, scalable and resilient mapping
	service. The LoST protocol specification only describes the protocol		service. The LoST protocol specification only describes the protocol
	used for individual seeker-originated queries. This document adds		used for individual seeker-originated queries. This document adds
	LoST operations that allow forest guides, resolver clusters and		LoST operations that allow forest guides, resolver clusters and
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	manually, based on local policies. A server can peer with any number		manually, based on local policies. A server can peer with any number
	of other servers. Forest guides peer with other forest guides;		of other servers. Forest guides peer with other forest guides;
	resolvers peer with forest guides and other resolvers (in the same		resolvers peer with forest guides and other resolvers (in the same
	cluster); authoritative mapping servers peer with forest guides and		cluster); authoritative mapping servers peer with forest guides and
	other authoritative servers, either in the same cluster or above or		other authoritative servers, either in the same cluster or above or
	below them in the tree. If the type of LoST role does not matter, we		below them in the tree. If the type of LoST role does not matter, we
	refer to LoST protocol participants as LoST nodes.		refer to LoST protocol participants as LoST nodes.
	Authoritative mapping servers push coverage regions "up" the tree,		Authoritative mapping servers push coverage regions "up" the tree,
	i.e., from child nodes to parent nodes. The child informs the parent		i.e., from child nodes to parent nodes. The child informs the parent
	of the geospatial or civic region that it covers. The service URL		of the geospatial or civic region that it covers. [TBD: How
	contains the LoST URL of the child node.		referenced?]
			The coverage regions of different authoritative servers can overlap.
			This should only happen if the authoritative servers are
			misconfigured or if there is a political dispute that involves
			competing claims for the same region. A server MUST detect such
			colliding claims and implement a policy to resolve the collision,
			either through an automated policy mechanism or manual intervention.
	This extension defines two new requests, <pushMappingsRequest> and		This extension defines two new requests, <pushMappingsRequest> and
	<getMappingsRequest>, that allow peering servers to exchange		<getMappingsRequest>, that allow peering servers to exchange
	mappings. These requests are used for all peering relationships and		mappings. These requests are used for all peering relationships and
	always contain mapping entries, but naturally the content of the data		always contain mapping entries, but naturally the content of the data
	exchanged differs.		exchanged differs.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 18 ¶
	peers, it pushes the new mappings to its peers. This information		peers, it pushes the new mappings to its peers. This information
	might arrive through non-LoST means, such as a manual addition to the		might arrive through non-LoST means, such as a manual addition to the
	local mappings database, or through another LoST node, via a		local mappings database, or through another LoST node, via a
	<pushMappings> request or a <getMappingsResponse> described later.		<pushMappings> request or a <getMappingsResponse> described later.
	Mappings in that request replace existing mappings with the same 'id'		Mappings in that request replace existing mappings with the same 'id'
	parameter and a more recent 'created' parameter. (Enforcing the		parameter and a more recent 'created' parameter. (Enforcing the
	latter avoids that a node that wakes up injects outdated information		latter avoids that a node that wakes up injects outdated information
	into the system.)		into the system.)
	Each peer keeps track of which peer it has exchanged which mapping		Each peer keeps track of which peer it has exchanged which mapping
	elements with. Mapping elements are identified by the 'id' and 'tag'		elements with. Mapping elements are identified by the 'source',
	parameters. A mapping is considered the same if these two attributes		'sourceID' and 'version' parameters. A mapping is considered the
	match. Nodes never push the same information to the same peer twice.		same if these three attributes match. Nodes never push the same
			information to the same peer twice.
			Instead of providing the mappings themselves, the LoST client can
			include references to mappings that have changed since the last
			request, by including <m> entries. The server then requests any out-
			of-date or missing mappings by including a subset of that list as <m>
			elements in a <getMappingsRequest> request.
	To delete a mapping, the content of the mapping is left empty. The		To delete a mapping, the content of the mapping is left empty. The
	node can delete the mapping from its internal mapping database, but		node can delete the mapping from its internal mapping database, but
	has to remember which peers it has distributed this update to. The		has to remember which peers it has distributed this update to. The
	mapping is identified only by the 'sourceId' and 'source' parameters;		mapping is identified only by the 'sourceId' and 'source' parameters;
	the other parameters are ignored if present. In other words, the		the other parameters are ignored if present. In other words, the
	delete operation affects all versions of a mapping.		delete operation affects all versions of a mapping.
	The response to <pushMappingsRequest> is <pushMappingsResponse>. It		The response to <pushMappingsRequest> is <pushMappingsResponse>. It
	only contains <errors> elements if there is an error condition. Only		only contains <errors> elements if there is an error condition. Only
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 15 ¶
	</mapping>		</mapping>
	<mapping source="lost:nj.us.example" sourceId="englewood"/>		<mapping source="lost:nj.us.example" sourceId="englewood"/>
	</mappings>		</mappings>
	</pushMappingsRequest>		</pushMappingsRequest>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync" />		<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync" />
	</pushMappingsResponse>		</pushMappingsResponse>
	Figure 1: Example pushMappingsRequest and pushMappingsResponse		Figure 1: Example pushMappingsRequest and pushMappingsResponse
	4. Synchronizing Mapping Stores via <getMappingsRequest> and		4. Synchronizing Mapping Stores via <getMappingsRequest> and
	<getMappingsResponse>		<getMappingsResponse>
			Get list of mappings identified by <m> elements. The server may not
			be able to return all such mappings, but the client can easily tell
			which mappings were unavailable since it can compare the mapping
			identifiers to those returned in the mapping elements.
			Errors TBD.
			5. Synchronizing Mapping Stores via <syncMappingsRequest> and
			<syncMappingsResponse>
	While the <pushMappingsRequest> request allows new mappings to		While the <pushMappingsRequest> request allows new mappings to
	propagate, it does not allow a newly-arriving node to acquire all		propagate, it does not allow a newly-arriving node to acquire all
	mappings maintained by another node. Thus, <getMappingsRequest> and		mappings maintained by another node. Therefore, we introduce
	<getMappingsResponse> are used to synchronize two mapping stores. A		<syncMappingsRequest> and <syncMappingsResponse> to synchronize two
	LoST node wanting to synchronize its mapping store with another node		mapping stores. A LoST node wanting to synchronize its mapping store
	issues a <getMappingsRequest>, containing an enumeration of the		with another node issues a <getMappingsRequest>, containing an
	current mapping source identifiers, tags and versions. The recipient		enumeration of the current mapping sources, source identifiers and
	of the request compares that list to its own list of mappings. It		versions in <m> elements. The recipient of the request compares that
	then returns an unordered set of mappings that are more recent than		list to its own list of mappings. It then returns an unordered set
	the ones identified in the <getMappingsRequest>. It also returns any		of mappings that are more recent than the ones identified in the
	mappings that it knows about that are not contained in the list at		<getMappingsRequest>. It also returns any mappings that it knows
	all. Thus, a querier can get the complete listing of mappings by		about that are not contained in the list at all. Thus, a querier can
	omitting 'm' elements altogether.		get the complete listing of mappings by omitting 'm' elements
			altogether.
			The querier can limit the scope of the mappings returned by adding
			'source', 'sourceId', and 'version' attributes to
			<getMappingsRequest>. 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 'version' is specified, 'sourceId' needs
			to be specified as well. If 'sourceId' is provided, the 'source'
			attribute also needs to be included. In other words, a querier
			cannot ask for all version 17 mappings regardless of source, for
			example. 'm' elements that do not match the <getMappingsRequest>
			attributes are silently ignored.
			Errors TBD.
	An example request and response is shown in Figure 2		An example request and response is shown in Figure 2
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lost1:sync">		<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lost1:sync"
			sourceId="lost:authoritative.example">
	<m sourceId="lost:authoritative.example"		<m sourceId="lost:authoritative.example"
	sourceId="abc123" version="1" />		sourceId="abc123" version="1" />
			<get sourceId="lost:munich.example.de"
			sourceId="xx" version="2" />
	</getMappingsRequest>		</getMappingsRequest>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<getMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync"		<getMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync"
	xmlns:p2="http://www.opengis.net/gml">		xmlns:p2="http://www.opengis.net/gml">
	<mappings>		<mappings>
	<mapping		<mapping
	expires="2007-01-26T01:44:33Z"		expires="2007-01-26T01:44:33Z"
	lastUpdated="2006-11-26T01:00:00Z"		lastUpdated="2006-11-26T01:00:00Z"
	source="lost:authoritative.example"		source="lost:authoritative.example"
	skipping to change at page 7, line 45 ¶		skipping to change at page 9, line 5 ¶
	</serviceBoundary>		</serviceBoundary>
	<uri>sip:nypd@ny.example.com</uri>		<uri>sip:nypd@ny.example.com</uri>
	<uri>xmpp:nypd@example.com</uri>		<uri>xmpp:nypd@example.com</uri>
	<serviceNumber>911</serviceNumber>		<serviceNumber>911</serviceNumber>
	</mapping>		</mapping>
	</mappings>		</mappings>
	</getMappingsResponse>		</getMappingsResponse>
	Figure 2: Example getMappingsRequest and getMappingsResponse		Figure 2: Example getMappingsRequest and getMappingsResponse
	5. Security Considerations		6. Security Considerations
	The LoST security considerations are discussed in [2]. The		The LoST security considerations are discussed in [2]. The
	operations described in this document involve mutually-trusting LoST		operations described in this document involve mutually-trusting LoST
	nodes. These nodes need to authenticate each other, using mechanisms		nodes. These nodes need to authenticate each other, using mechanisms
	such as HTTP Digest, HTTP Basic over TLS or TLS client and server		such as HTTP Digest, HTTP Basic over TLS or TLS client and server
	certificates. Nodes implementing LoST MUST implement HTTP Basic		certificates. Nodes implementing LoST MUST implement HTTP Basic
	authentication over TLS and MAY implement other authentication		authentication over TLS and MAY implement other authentication
	mechanisms.		mechanisms.
	6. IANA Considerations		7. IANA Considerations
	6.1. LoST Synchronization Namespace Registration		7.1. LoST Synchronization Namespace Registration
	URI: urn:ietf:params:xml:ns:lost1:sync		URI: urn:ietf:params:xml:ns:lost1:sync
	Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne		Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne
	(hgs@cs.columbia.edu).		(hgs@cs.columbia.edu).
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	skipping to change at page 8, line 38 ¶		skipping to change at page 9, line 45 ¶
	<h1>Namespace for LoST server synchronization</h1>		<h1>Namespace for LoST server synchronization</h1>
	<h2>urn:ietf:params:xml:ns:lost1:sync</h2>		<h2>urn:ietf:params:xml:ns:lost1:sync</h2>
	<p>See <a href="[URL of published RFC]">RFCXXXX		<p>See <a href="[URL of published RFC]">RFCXXXX
	[NOTE TO IANA/RFC-EDITOR:		[NOTE TO IANA/RFC-EDITOR:
	Please replace XXXX with the RFC number of this		Please replace XXXX with the RFC number of this
	specification.]</a>.</p>		specification.]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	7. Acknowledgments		8. Acknowledgments
	Your name here.		Andrew Newton provided helpful input.
	8. RelaxNG		9. RelaxNG
	TBD		TBD
	9. References		10. References
	9.1. Normative References
			10.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Hardie, T., "LoST: A Location-to-Service Translation Protocol",		[2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig,
	draft-ietf-ecrit-lost-02 (work in progress), October 2006.		"LoST: A Location-to-Service Translation Protocol",
			draft-ietf-ecrit-lost-07 (work in progress), February 2008.
	9.2. Informative References		10.2. Informative References
	[3] Schulzrinne, H., "Location-to-URL Mapping Architecture and		[3] Schulzrinne, H., "Location-to-URL Mapping Architecture and
	Framework", draft-ietf-ecrit-mapping-arch-00 (work in progress),		Framework", draft-ietf-ecrit-mapping-arch-03 (work in progress),
	August 2006.		September 2007.
	Author's Address		Author's Address
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs+ecrit@cs.columbia.edu		Email: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 25 change blocks.
	51 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/