idnits 2.17.1 

draft-ietf-ecrit-lost-planned-changes-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (October 23, 2018) is 2012 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


2	ecrit                                                           B. Rosen
3	Internet-Draft                                          October 23, 2018
4	Intended status: Standards Track
5	Expires: April 26, 2019

7	            Validation of Locations Around a Planned Change
8	                draft-ietf-ecrit-lost-planned-changes-02

10	Abstract

12	   This document defines an extension to LoST (RFC5222) that allows a
13	   planned change to the data in the LoST server to occur.  Records that
14	   previously were valid will become invalid at a date in the future,
15	   and new locations will become valid after the date.  The extension
16	   adds two elements to the <findservice> request: A URI to be used to
17	   inform the LIS that previously valid locations will be invalid after
18	   the planned change date, and add a date which requests the server to
19	   perform validation as of the date specified.  It also adds an
20	   optional Time-To-Live element to the response, which informs clients
21	   about the current expected lifetime of the validation.  This document
22	   also provides a conventional XML schema for LoST, as backwards
23	   compatible alternative to the RelaxNG schema in RFC5222

25	Status of This Memo

27	   This Internet-Draft is submitted in full conformance with the
28	   provisions of BCP 78 and BCP 79.

30	   Internet-Drafts are working documents of the Internet Engineering
31	   Task Force (IETF).  Note that other groups may also distribute
32	   working documents as Internet-Drafts.  The list of current Internet-
33	   Drafts is at https://datatracker.ietf.org/drafts/current/.

35	   Internet-Drafts are draft documents valid for a maximum of six months
36	   and may be updated, replaced, or obsoleted by other documents at any
37	   time.  It is inappropriate to use Internet-Drafts as reference
38	   material or to cite them other than as "work in progress."

40	   This Internet-Draft will expire on April 26, 2019.

42	Copyright Notice

44	   Copyright (c) 2018 IETF Trust and the persons identified as the
45	   document authors.  All rights reserved.

47	   This document is subject to BCP 78 and the IETF Trust's Legal
48	   Provisions Relating to IETF Documents
49	   (https://trustee.ietf.org/license-info) in effect on the date of
50	   publication of this document.  Please review these documents
51	   carefully, as they describe your rights and restrictions with respect
52	   to this document.  Code Components extracted from this document must
53	   include Simplified BSD License text as described in Section 4.e of
54	   the Trust Legal Provisions and are provided without warranty as
55	   described in the Simplified BSD License.

57	Table of Contents

59	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
60	   2.  Conventions used in this document . . . . . . . . . . . . . .   4
61	   3.  <plannedChange> element . . . . . . . . . . . . . . . . . . .   4
62	   4.  <locationInvalidated> object  . . . . . . . . . . . . . . . .   4
63	   5.  URI Not Stored Warning  . . . . . . . . . . . . . . . . . . .   5
64	   6.  Time-To-Live (TTL) in Response  . . . . . . . . . . . . . . .   5
65	   7.  Replacement XML schema  . . . . . . . . . . . . . . . . . . .   6
66	   8.  Extension XML schema  . . . . . . . . . . . . . . . . . . . .  14
67	   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
68	   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
69	     10.1.  Replacement Schema Registration  . . . . . . . . . . . .  16
70	     10.2.  Replacement Schema Registration  . . . . . . . . . . . .  16
71	     10.3.  LoST Namespace Registration  . . . . . . . . . . . . . .  16
72	   11. Normative References  . . . . . . . . . . . . . . . . . . . .  17
73	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

75	1.  Introduction

77	   This document describes an update to the LoST protocol + which allows
78	   a <findservice> request to optionally add a URI and a date to be used
79	   with planned changes to the underlying location information in the
80	   server.  The URI is retained by the LoST server, associated with the
81	   data record that was validated, and used to notify the LIS (the LoST
82	   client) when a location which was previously valid will become
83	   invalid.  The date is used by the client to ask the server to perform
84	   validation as of a future date.  In addition to this mechanism, the
85	   <findserviceResponse> is also extended to provide a Time-To-Live
86	   (TTL) for validation, after which the client should revalidate the
87	   location.

89	   Validation of civic locations involves dealing with data that changes
90	   over time.  A typical example is a portion of a county or province
91	   that was not part of a municipality is "annexed" to a municipality.
92	   Prior to the change, the content of the PIDF-LO A3 element would be
93	   blank, or represent some other value and after the change would be
94	   the municipality that annexed that part of the county/province.  This
95	   kind of annexation has an effective date and time (typically 00:00 on
96	   the first or last day of a month).

98	   Records in a LIS must change around these kinds of events.  The old
99	   record must be discarded, and a new, validated record must be loaded
100	   into the LIS.  It is often difficult for the LIS operator to know
101	   that records must be changed around such events.  There are other
102	   circumstances where locations that were previously valid become
103	   invalid, such as a street renaming or renumbering event.  As RFC5222
104	   defines validation, the only way for a LIS to discover such changes
105	   was to periodically revalidate its entire database.  Of course, this
106	   would not facilitate timely changes, is not coordinated with the
107	   actual change event, and also adds significant load to the LoST
108	   server.  Even if re-validation is contemplated, the server has no
109	   mechanism to control, or even suggest the time period for
110	   revalidation

112	   This extension allows the client to provide a stable URI that is
113	   retained by the server associated with the location information used
114	   in the request.  In the event of a planned change, or any other
115	   circumstance where the location becomes invalid, the server sends a
116	   notification to the URI informing it of a change.  The notification
117	   contains the date and time when the location becomes invalid.

119	   Ideally, following such a notification, the LIS will prepare a new
120	   record to be inserted in its active database, that becomes active at
121	   the precise planned event date and time, at which point it would also
122	   delete the old record.  However, the new record has to be valid, and
123	   the LIS would like to validate it prior to the planned change event.
124	   If it requests validation before the planned event, the server
125	   (without this extension) would inform the client that the location
126	   was invalid.  This extension includes an optional "as of" date and
127	   time in the request that allows the LoST server to provide validation
128	   as of the date and time specified, as opposed to the "as of now"
129	   implied in the current LoST protocol.

131	   When it is not practical or advisable for the LIS to maintain stable
132	   URIs for all of its records, periodic revalidation can be still used
133	   to maintain the data in the LIS.  However, the server should be able
134	   to control the rate of such revalidation.  For this purpose, a new
135	   TTL element is included in the <findserviceResponse> which provides
136	   advice from the server to the LIS of when validation is suggested.

138	   There are quite a few implementations of LoST.  Experience with these
139	   implementations indicates that the RelaxNG schema is very difficult
140	   to deal with, because the tools that the implementors use don't
141	   support it, and their staff is unfamiliar with it.  Alternative
142	   schemas have been circulated, which is undesirable, as they may not
143	   be in conformance to the RelaxNG schema in [RFC5222].  This document
144	   provides an XML schema that replaces the RelaxNG schema.  It can be
145	   used by any implementation interchangeably with the RelaxNG schema.

147	2.  Conventions used in this document

149	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151	   document are to be interpreted as described in [RFC2119].

153	   "Server" in this document refers to the LoST server and "Client" is
154	   the LoST client, even when the server is performing an operation on
155	   the client.

157	3.  <plannedChange> element

159	   This document defines a new element to <findService> called
160	   "plannedChange".  This element contains two attributes: 'uri' and
161	   'asOf'.  The 'uri' attribute MUST be a URI with a scheme of HTTPS.
162	   The URI will be stored by the server against the location in the
163	   request for subsequent use with the notification function defined
164	   below.  To minimize storage requirements of at the server, the length
165	   of the URI MUST be 256 bytes or less.  Each client of the server may
166	   only store one URI against a location, where "location" is defined by
167	   policy at the server, since a given unique location may have many
168	   combinations of location elements that resolve to the same location.
169	   If the server receives a 'uri' for the same location from the same
170	   client, the URI in the request replaces the URI it previously
171	   retained.  Policy at the server may limit how many URIs it retains
172	   for a given location.  A new warning is defined below to be used to
173	   indicate that the URI has not been stored.  If the location in the
174	   request is invalid, the URI will not be stored and the warning will
175	   be returned.

177	   The 'asOf' attribute contains a date and time.  The server will
178	   validate the location in the request as of the date specified, taking
179	   into account planned changes.  This allows the client to verify that
180	   it can make changes in the LIS commensurate with changes in the LoST
181	   server by validating locations in advance of a change.

183	4.  <locationInvalidated> object

185	   When the server needs to invalidate a location where the client
186	   provided a URI in <plannedChange>, the server executes an HTTPS POST
187	   containing <locationInvalidated> to the URI previously provided.
188	   This is the notice from the server to the client that the location
189	   may be invalid and should be revalidated.  <locationInvalidated>
190	   contains an 'invalidAsOf' attribute that specifies when the location
191	   may become invalid.  If the date/time in 'invalidAsOf' is earlier
192	   than the time the <locationInvalidated> was sent, the location may
193	   already be invalid and the LIS should take immediate action.  If the
194	   POST operation fails, the server MAY retry the operation immediately,
195	   and if it fails again, retry the operation at a later time.

197	5.  URI Not Stored Warning

199	   A new warning is added to the exceptionContainer, 'uriNotStored'.
200	   This warning MUST NOT be returned unless the <plannedChange> element
201	   was found in the corresponding request.  The warning is returned when
202	   the server decides not to store the URI found in the <plannedChange>
203	   element.  As discussed above, this may occur because, among other
204	   reasons, the policy at the server limits how many URIs will be stored
205	   against a specific location, the URI is not well formed or the policy
206	   at the server has some other restriction on the feature.

208	6.  Time-To-Live (TTL) in Response

210	   A new <ttl> element is added to the <findserviceResponse>.  The <ttl>
211	   element contains a date and time after which the client may wish to
212	   revalidate the location at the server.  This element MAY be added by
213	   the server if validation is requested in the response.  The form of
214	   the element is the 'expires' attribute pattern, which allows explicit
215	   'NO CACHE' and 'NO EXPIRATION' values to be returned in the <ttl>
216	   element.  'NO CACHE' has no meaning and MUST NOT be returned in TTL.
217	   'NO EXPIRATION' means the server does not have any suggested
218	   revalidation period.

220	   Selecting a revalidation interval is a complex balancing of
221	   timeliness, server load, stability of the underlying data, and policy
222	   of the LoST server.  Too short, and load on the server may overwhelm
223	   it.  Too long and invalid data may persist in the server for too
224	   long.  The URI mechanism provides timely notice to coordinate
225	   changes, but even with it, it is often advisable to revalidate data
226	   eventually.

228	   In areas that have little change in data, such as fully built out,
229	   stable communities already part of a municipality, it may be
230	   reasonable to set revalidation periods of 6 months or longer,
231	   especially if the URI mechanism is widely deployed at both the server
232	   and the clients.  In areas that are quickly growing, 20-30 day
233	   revalidation may be more appropriate even though such revalidation
234	   would be the majority of the traffic on the LoST server.

236	   When a planned change is made, typically the TTL value for the
237	   affected records is lowered, so that revalidation is forced soon
238	   after the change is implemented.  It is not advisable to set the
239	   expiration precisely at the planned change time if a large number of
240	   records will be changed, since that would cause a large spike in
241	   traffic at the change time.  Rather, the expiration time should have
242	   a random additional time added to it to spread out the load.

244	7.  Replacement XML schema

246	   The Relax NG schema in [RFC5222] is replaced with the following XML
247	   schema:

249	 <?xml version="1.0" encoding="UTF-8"?>
250	 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
251	            xmlns="urn:ietf:params:xml:ns:lost1"
252	            targetNamespace="urn:ietf:params:xml:ns:lost1"
253	            elementFormDefault="qualified">

255	   <xs:element name="findService">
256	     <xs:complexType>
257	       <xs:sequence>
258	         <xs:group ref="requestLocation"/>
259	         <xs:group ref="commonRequestPattern"/>
260	       </xs:sequence>
261	       <xs:attribute name="validateLocation" type="xs:boolean"/>
262	       <xs:attribute name="serviceBoundary">
263	         <xs:simpleType>
264	           <xs:restriction base="xs:token">
265	             <xs:enumeration value="reference"/>
266	             <xs:enumeration value="value"/>
267	           </xs:restriction>
268	         </xs:simpleType>
269	       </xs:attribute>
270	       <xs:attribute name="recursive" type="xs:boolean"/>
271	     </xs:complexType>
272	   </xs:element>

274	   <xs:element name="listServices">
275	     <xs:complexType>
276	       <xs:group ref="commonRequestPattern"/>
277	     </xs:complexType>
278	   </xs:element>

280	   <xs:element name="listServicesByLocation">
281	     <xs:complexType>
282	       <xs:sequence>
283	         <xs:group ref="requestLocation"/>
284	         <xs:group ref="commonRequestPattern"/>
285	       </xs:sequence>
286	       <xs:attribute name="recursive" type="xs:boolean"/>
287	     </xs:complexType>
288	   </xs:element>
289	   <xs:element name="getServiceBoundary">
290	     <xs:complexType>
291	       <xs:group ref="extensionPoint"/>
292	       <xs:attributeGroup ref="serviceBoundaryKey"/>
293	     </xs:complexType>
294	   </xs:element>

296	   <xs:element name="findServiceResponse">
297	     <xs:complexType>
298	       <xs:sequence>
299	         <xs:element ref="mapping" maxOccurs="unbounded"/>
300	         <xs:element ref="locationValidation" minOccurs="0"/>
301	         <xs:group ref="commonResponsePattern"/>
302	         <xs:group ref="locationUsed"/>
303	       </xs:sequence>
304	     </xs:complexType>
305	   </xs:element>

307	   <xs:element name="listServicesResponse">
308	     <xs:complexType>
309	       <xs:sequence>
310	         <xs:element ref="serviceList"/>
311	         <xs:group ref="commonResponsePattern"/>
312	       </xs:sequence>
313	     </xs:complexType>
314	   </xs:element>

316	   <xs:element name="listServicesByLocationResponse">
317	     <xs:complexType>
318	       <xs:sequence>
319	         <xs:element ref="serviceList"/>
320	         <xs:group ref="commonResponsePattern"/>
321	         <xs:group ref="locationUsed"/>
322	       </xs:sequence>
323	     </xs:complexType>
324	   </xs:element>

326	   <xs:element name="getServiceBoundaryResponse">
327	     <xs:complexType>
328	       <xs:sequence>
329	         <xs:group ref="serviceBoundary"/>
330	         <xs:group ref="commonResponsePattern"/>
331	       </xs:sequence>
332	     </xs:complexType>
333	   </xs:element>

335	   <xs:group name="commonRequestPattern">
336	     <xs:sequence>
337	       <xs:group ref="service"/>
338	       <xs:element ref="path" minOccurs="0"/>
339	       <xs:group ref="extensionPoint"/>
340	     </xs:sequence>
341	   </xs:group>

343	   <xs:group name="commonResponsePattern">
344	     <xs:sequence>
345	       <xs:element ref="warnings" minOccurs="0" maxOccurs="unbounded"/>
346	       <xs:element ref="path"/>
347	       <xs:group ref="extensionPoint"/>
348	     </xs:sequence>
349	   </xs:group>

351	   <xs:group name="requestLocation">
352	     <xs:sequence>
353	       <xs:element ref="location" maxOccurs="unbounded"/>
354	     </xs:sequence>
355	   </xs:group>

357	   <xs:element name="location">
358	     <xs:complexType>
359	       <xs:complexContent>
360	         <xs:extension base="locationInformation">
361	           <xs:attribute name="id" type="xs:token" use="required"/>
362	         </xs:extension>
363	       </xs:complexContent>
364	     </xs:complexType>
365	   </xs:element>

367	   <xs:complexType name="locationInformation">
368	     <xs:group ref="extensionPoint" maxOccurs="unbounded"/>
369	     <xs:attribute name="profile" type="xs:NMTOKEN"/>
370	   </xs:complexType>

372	   <xs:group name="serviceBoundary">
373	     <xs:sequence>
374	       <xs:element ref="serviceBoundary" maxOccurs="unbounded"/>
375	     </xs:sequence>
376	   </xs:group>

378	   <xs:element name="serviceBoundary" type="locationInformation"/>

380	   <xs:element name="serviceBoundaryReference">
381	     <xs:complexType>
382	       <xs:group ref="extensionPoint"/>
383	       <xs:attributeGroup ref="source"/>
384	       <xs:attributeGroup ref="serviceBoundaryKey"/>

386	     </xs:complexType>
387	   </xs:element>

389	   <xs:attributeGroup name="serviceBoundaryKey">
390	     <xs:attribute name="key" type="xs:token" use="required"/>
391	   </xs:attributeGroup>

393	   <xs:element name="path">
394	     <xs:complexType>
395	       <xs:sequence>
396	         <xs:element ref="via" maxOccurs="unbounded"/>
397	       </xs:sequence>
398	     </xs:complexType>
399	   </xs:element>

401	   <xs:element name="via">
402	     <xs:complexType>
403	       <xs:group ref="extensionPoint"/>
404	       <xs:attributeGroup ref="source"/>
405	     </xs:complexType>
406	   </xs:element>

408	   <xs:group name="locationUsed">
409	     <xs:sequence>
410	       <xs:element ref="locationUsed" minOccurs="0"/>
411	     </xs:sequence>
412	   </xs:group>

414	   <xs:element name="locationUsed">
415	     <xs:complexType>
416	       <xs:attribute name="id" type="xs:token" use="required"/>
417	     </xs:complexType>
418	   </xs:element>

420	   <xs:attributeGroup name="expires">
421	     <xs:attribute name="expires" use="required">
422	       <xs:simpleType>
423	         <xs:union memberTypes="xs:dateTime">
424	           <xs:simpleType>
425	             <xs:restriction base="xs:token">
426	               <xs:enumeration value="NO-CACHE"/>
427	             </xs:restriction>
428	           </xs:simpleType>
429	           <xs:simpleType>
430	             <xs:restriction base="xs:token">
431	               <xs:enumeration value="NO-EXPIRATION"/>
432	             </xs:restriction>
433	           </xs:simpleType>

435	         </xs:union>
436	       </xs:simpleType>
437	     </xs:attribute>
438	   </xs:attributeGroup>

440	   <xs:simpleType name="qnameList">
441	     <xs:list itemType="xs:QName"/>
442	   </xs:simpleType>

444	   <xs:element name="mapping">
445	     <xs:complexType>
446	       <xs:sequence>
447	         <xs:element ref="displayName"
448	              minOccurs="0" maxOccurs="unbounded"/>
449	         <xs:group ref="service"/>
450	         <xs:choice minOccurs="0">
451	           <xs:group ref="serviceBoundary"/>
452	           <xs:element ref="serviceBoundaryReference"/>
453	         </xs:choice>
454	         <xs:element ref="uri"
455	              minOccurs="0" maxOccurs="unbounded"/>
456	         <xs:element ref="serviceNumber" minOccurs="0"/>
457	         <xs:group ref="extensionPoint"/>
458	       </xs:sequence>
459	       <xs:attributeGroup ref="expires"/>
460	       <xs:attribute name="lastUpdated" type="xs:dateTime"
461	             use="required"/>
462	       <xs:attributeGroup ref="source"/>
463	       <xs:attribute name="sourceId" type="xs:token"
464	             use="required"/>
465	       <xs:attributeGroup ref="message"/>
466	     </xs:complexType>
467	   </xs:element>

469	   <xs:element name="displayName">
470	     <xs:complexType>
471	       <xs:simpleContent>
472	         <xs:extension base="xs:string">
473	           <xs:attribute ref="xml:lang" use="required"/>
474	         </xs:extension>
475	       </xs:simpleContent>
476	     </xs:complexType>
477	   </xs:element>

479	   <xs:element name="uri" type="xs:anyURI"/>

481	   <xs:element name="serviceNumber">
482	     <xs:simpleType>
483	       <xs:restriction base="xs:token">
484	         <xs:pattern value="[0-9*#]+"/>
485	       </xs:restriction>
486	     </xs:simpleType>
487	   </xs:element>

489	   <xs:element name="locationValidation">
490	     <xs:complexType>
491	       <xs:sequence>
492	         <xs:element ref="valid" minOccurs="0"/>
493	         <xs:element ref="invalid" minOccurs="0"/>
494	         <xs:element ref="unchecked" minOccurs="0"/>
495	         <xs:group ref="extensionPoint"/>
496	       </xs:sequence>
497	     </xs:complexType>
498	   </xs:element>

500	   <xs:element name="valid" type="qnameList"/>

502	   <xs:element name="invalid" type="qnameList"/>

504	   <xs:element name="unchecked" type="qnameList"/>

506	   <xs:complexType name="exceptionContainer">
507	     <xs:sequence>
508	       <xs:choice minOccurs="0" maxOccurs="unbounded">
509	         <xs:element ref="badRequest"/>
510	         <xs:element ref="internalError"/>
511	         <xs:element ref="serviceSubstitution"/>
512	         <xs:element ref="defaultMappingReturned"/>
513	         <xs:element ref="forbidden"/>
514	         <xs:element ref="notFound"/>
515	         <xs:element ref="loop"/>
516	         <xs:element ref="serviceNotImplemented"/>
517	         <xs:element ref="serverTimeout"/>
518	         <xs:element ref="serverError"/>
519	         <xs:element ref="locationInvalid"/>
520	         <xs:element ref="locationProfileUnrecognized"/>
521	       </xs:choice>
522	       <xs:group ref="extensionPoint"/>
523	     </xs:sequence>
524	     <xs:attributeGroup ref="source"/>
525	   </xs:complexType>

527	   <xs:element name="errors" type="exceptionContainer"/>

529	   <xs:element name="warnings" type="exceptionContainer"/>
530	   <xs:complexType name="basicException">
531	     <xs:annotation>
532	       <xs:documentation>
533	         Exception pattern.
534	       </xs:documentation>
535	     </xs:annotation>
536	     <xs:group ref="extensionPoint"/>
537	     <xs:attributeGroup ref="message"/>
538	   </xs:complexType>

540	   <xs:element name="badRequest" type="basicException"/>

542	   <xs:element name="internalError" type="basicException"/>

544	   <xs:element name="serviceSubstitution" type="basicException"/>

546	   <xs:element name="defaultMappingReturned" type="basicException"/>

548	   <xs:element name="forbidden" type="basicException"/>

550	   <xs:element name="notFound" type="basicException"/>

552	   <xs:element name="loop" type="basicException"/>

554	   <xs:element name="serviceNotImplemented" type="basicException"/>

556	   <xs:element name="serverTimeout" type="basicException"/>

558	   <xs:element name="serverError" type="basicException"/>

560	   <xs:element name="locationInvalid" type="basicException"/>

562	   <xs:element name="locationValidationUnavailable"
563	           type="basicException"/>

565	   <xs:element name="locationProfileUnrecognized">
566	     <xs:complexType>
567	       <xs:complexContent>
568	         <xs:extension base="basicException">
569	           <xs:attribute name="unsupportedProfiles"
570	               type="xs:NMTOKENS" use="required"/>
571	         </xs:extension>
572	       </xs:complexContent>
573	     </xs:complexType>
574	   </xs:element>

576	   <xs:element name="redirect">
577	     <xs:complexType>
578	       <xs:group ref="extensionPoint"/>
579	       <xs:attribute name="target" type="appUniqueString"
580	           use="required"/>
581	       <xs:attributeGroup ref="source"/>
582	       <xs:attributeGroup ref="message"/>
583	     </xs:complexType>
584	   </xs:element>

586	   <xs:attributeGroup name="message">
587	     <xs:attribute name="message" type="xs:token"/>
588	     <xs:attribute ref="xml:lang"/>
589	   </xs:attributeGroup>

591	   <xs:group name="service">
592	     <xs:sequence>
593	       <xs:element ref="service" minOccurs="0"/>
594	     </xs:sequence>
595	   </xs:group>

597	   <xs:element name="service" type="xs:anyURI"/>

599	   <xs:simpleType name="appUniqueString">
600	     <xs:restriction base="xs:token">
601	       <xs:pattern value="([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+"/>
602	     </xs:restriction>
603	   </xs:simpleType>

605	   <xs:attributeGroup name="source">
606	     <xs:attribute name="source" type="appUniqueString" use="required"/>
607	   </xs:attributeGroup>

609	   <xs:element name="serviceList">
610	     <xs:simpleType>
611	       <xs:list itemType="xs:anyURI"/>
612	     </xs:simpleType>
613	   </xs:element>

615	   <xs:group name="notLost">
616	     <xs:annotation>
617	       <xs:documentation>
618	         Any element not in the LoST namespace.
619	       </xs:documentation>
620	     </xs:annotation>
621	     <xs:choice>
622	       <xs:any namespace="##other" processContents="skip"/>
623	       <xs:any namespace="##local" processContents="skip"/>
624	     </xs:choice>
625	   </xs:group>
626	   <xs:group name="anyElement">
627	     <xs:annotation>
628	       <xs:documentation>
629	         A wildcard pattern for including any element
630	         from any other namespace.
631	       </xs:documentation>
632	     </xs:annotation>
633	     <xs:sequence>
634	       <xs:any processContents="skip"
635	           minOccurs="0" maxOccurs="unbounded"/>
636	     </xs:sequence>
637	   </xs:group>

639	   <xs:attributeGroup name="anyElement">
640	     <xs:annotation>
641	       <xs:documentation>
642	         A wildcard pattern for including any element
643	         from any other namespace.
644	       </xs:documentation>
645	     </xs:annotation>
646	     <xs:anyAttribute processContents="skip"/>
647	   </xs:attributeGroup>

649	   <xs:group name="extensionPoint">
650	     <xs:annotation>
651	       <xs:documentation>
652	         A point where future extensions
653	         (elements from other namespaces)
654	         can be added.
655	       </xs:documentation>
656	     </xs:annotation>
657	     <xs:sequence>
658	       <xs:group ref="notLost"
659	            minOccurs="0" maxOccurs="unbounded"/>
660	     </xs:sequence>
661	   </xs:group>

663	 </xs:schema>

665	8.  Extension XML schema

667	   This schema provides the extension to the prior section schema for
668	   planned changes:

670	<?xml version="1.0" encoding="UTF-8"?>
671	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
672	           xmlns="urn:ietf:params:xml:ns:lostPlannedChange1"
673	           targetNamespace="urn:ietf:params:xml:ns:lostPlannedChange1"
674	           elementFormDefault="qualified">
675	     <!-- Import base Lost -->
676	     <xs:import namespace="urn:ietf:params:xml:ns:lost1"/>
677	<!-- extend the extensionPoint of commonRequestPattern of findService
678	                                                       to include:  -->
679	        xs:group ref="plannedChange" minOccurs="1"/>

681	<!-- where -->
682	       <xs:group name="plannedChange">
683	           <xs:sequence>
684	              <xs:element ref="uri" type="xs:anyURI" />
685	              <xs:element ref="invalidAsOf" type="xs:dateTime" />
686	              <xs:any namespace="##other" processContents="lax"
687	                 minOccurs="0" maxOccurs="unbounded"/>
688	           </xs:sequence>
689	        </xs:group>

691	<!-- extend the extensionPoint of commonResponsePattern in
692	                          findServiceResponse to include: -->
693	           <xs:atttribute name="asOf" type="xs:dateTime" minOccurs="0"/>
694	           <xs:element ref="ttl" type="expires" minOccurs="0" />

696	<!-- extend the extensionPoint of extensionContainer to include: -->
697	           <xs:element ref="uriNotStored"/>
698	<!-- where -->
699	           <xs:element name="uriNotStored" type="basicException"/>

701	</xs:schema>

703	9.  Security Considerations

705	   As an extension to LoST, this document inherits the security issues
706	   raised in [RFC5222].  The server could be tricked into storing a
707	   malicious URI which, when sent the locationInvalidated object could
708	   trigger something untoward.  The server MUST NOT accept any data from
709	   the client in response to POSTing the locationInvalidated.

711	   The server is subject to abuse by clients because it is being asked
712	   to store something and may need to send data to an uncontrolled URI.
713	   Clients could request many URIs for the same location for example.
714	   The server MUST have policy that limits use of this mechanism by a
715	   given client.  If the policy is exceeded, the server returns the
716	   'uriNotStored' warning.  The server MUST validate that the content of
717	   the 'uri' attribute sent is syntactically valid and meets the 256
718	   bytes limit.  When sending the locationInvalidated object to the URI
719	   stored, the server MUST protect itself against common HTTP
720	   vulnerabilities.

722	   The mutual authentication between client and server is RECOMMENDED
723	   for both the initial <findService> operation that requests storing
724	   the URI and the sending of the 'locationInvalidated' object.  The
725	   server should be well known to the client, and its credential should
726	   be learned in a reliable way.  For example, a public safety system
727	   operating the LoST server may have a credential traceable to a well
728	   known Certificate Authority known to provide credentials for public
729	   safety agencies.  Many of the clients will be operated by local ISPs
730	   or other service providers where the server operator can reasonably
731	   obtain a good credential to use for the URI.  Where the server does
732	   not recognize the client, its policy MAY limit the use of this
733	   feature beyond what it would limit a client it recognized.

735	10.  IANA Considerations

737	10.1.  Replacement Schema Registration

739	      URI:  urn:ietf:params:xml:schema:lost3
740	      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
741	         (br@brianrosen.net).

743	      The XML Schema is found in <xref target="schema"/>.

745	10.2.  Replacement Schema Registration

747	      URI:  urn:ietf:params:xml:schema:lostPlannedChange1
748	      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
749	         (br@brianrosen.net).

751	      The XML Schema is found in <xref target="extSchema"100/>.

753	10.3.  LoST Namespace Registration
754	      URI:  urn:ietf:params:xml:ns:lost-plannedChange1

756	      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
757	         (br@brianrosen.net).

759	      XML:

761	   BEGIN
762	   <?xml version="2.0"?>
763	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
764	     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
765	   <html xmlns="http://www.w3.org/1999/xhtml">
766	   <head>
767	     <meta http-equiv="content-type"
768	           content="text/html;charset=iso-8859-1"/>
769	     <title>LoST Planned Change Namespace</title>
770	   </head>
771	   <body>
772	     <h1>Namespace for LoST Planned Change extension</h1>
773	     <h2>urn:ietf:params:xml:ns:lost-plannedChange1</h2>
774	   <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
775	      RFC????</a>.</p>
776	   </body>
777	   </html>
778	   END

780	11.  Normative References

782	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
783	              Requirement Levels", BCP 14, RFC 2119,
784	              DOI 10.17487/RFC2119, March 1997,
785	              <https://www.rfc-editor.org/info/rfc2119>.

787	   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
788	              Tschofenig, "LoST: A Location-to-Service Translation
789	              Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
790	              <https://www.rfc-editor.org/info/rfc5222>.

792	Author's Address

794	   Brian Rosen
795	   470 Conrad Dr
796	   Mars, PA  16046
797	   US

799	   EMail: br@brianrosen.net