idnits 2.17.1 

draft-ietf-ecrit-lost-planned-changes-04.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:
  ----------------------------------------------------------------------------

  == There is 1 instance of lines with non-ascii characters in the document.


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

  == The 'Updates: ' line in the draft header should list only the _numbers_
     of the RFCs which will be updated by this document (if approved); it
     should not include the word 'RFC' in the list.


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

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

  -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  -- The document date (19 August 2021) is 974 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 (~~), 3 warnings (==), 2 comments (--).

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

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


2	ecrit                                                           B. Rosen
3	Internet-Draft                                            19 August 2021
4	Updates: RFC5222 (if approved)
5	Intended status: Standards Track
6	Expires: 20 February 2022

8	            Validation of Locations Around a Planned Change
9	                draft-ietf-ecrit-lost-planned-changes-04

11	Abstract

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

26	Status of This Memo

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

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

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

41	   This Internet-Draft will expire on 20 February 2022.

43	Copyright Notice

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

48	   This document is subject to BCP 78 and the IETF Trust's Legal
49	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
50	   license-info) in effect on the date of publication of this document.
51	   Please review these documents carefully, as they describe your rights
52	   and restrictions with respect to this document.  Code Components
53	   extracted from this document must include Simplified BSD License text
54	   as described in Section 4.e of the Trust Legal Provisions and are
55	   provided without warranty as 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  . . . . . . . . . . . . . . . .   5
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  . . . . . . . . . . . . . . . . . . . .  15
67	   9.  locationInvalidated Schema  . . . . . . . . . . . . . . . . .  16
68	   10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
69	   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
70	     11.1.  Replacement XML Schema Registration  . . . . . . . . . .  17
71	     11.2.  Planned Change Extension XML Schema Registration . . . .  17
72	     11.3.  locationInvalidated XML Schema Registration  . . . . . .  18
73	   12. Normative References  . . . . . . . . . . . . . . . . . . . .  19
74	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

76	1.  Introduction

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

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

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

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

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

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

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

148	2.  Conventions used in this document

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

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

158	3.  <plannedChange> element

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

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

184	4.  <locationInvalidated> object

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

199	   The LoST server is NOT REQUIRED to store the Location Information
200	   supplied in the original findService request.  This means the server
201	   may not know if a planned change will in fact invalidate the location
202	   stored in the LoST client, because changes could be made in the LoST
203	   server that do not affect validation of the Location Information.
204	   The LoST client may find that upon revalidation with the changed
205	   server state, the validation data is the same as it was before the
206	   notification was received.

208	5.  URI Not Stored Warning

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

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

221	   A new <ttl> element is added to the <findserviceResponse>.  The <ttl>
222	   element contains a date and time after which the client may wish to
223	   revalidate the location at the server.  This element MAY be added by
224	   the server if validation is requested in the response.  The form of
225	   the element is the 'expires' attribute pattern, which allows explicit
226	   'NO CACHE' and 'NO EXPIRATION' values to be returned in the <ttl>
227	   element.  'NO CACHE' has no meaning and MUST NOT be returned in TTL.
228	   'NO EXPIRATION' means the server does not have any suggested
229	   revalidation period.

231	   Selecting a revalidation interval is a complex balancing of
232	   timeliness, server load, stability of the underlying data, and policy
233	   of the LoST server.  Too short, and load on the server may overwhelm
234	   it.  Too long and invalid data may persist in the server for too
235	   long.  The URI mechanism provides timely notice to coordinate
236	   changes, but even with it, it is often advisable to revalidate data
237	   eventually.

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

247	   When a planned change is made, typically the TTL value for the
248	   affected records is lowered, so that revalidation is forced soon
249	   after the change is implemented.  It is not advisable to set the
250	   expiration precisely at the planned change time if a large number of
251	   records will be changed, since that would cause a large spike in
252	   traffic at the change time.  Rather, the expiration time should have
253	   a random additional time added to it to spread out the load.

255	7.  Replacement XML schema

257	   This schema is an informative alternative to The Relax NG schema in
258	   [RFC5222]

260	 <?xml version="1.0" encoding="UTF-8"?>
261	 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
262	            xmlns="urn:ietf:params:xml:ns:lost1"
263	            targetNamespace="urn:ietf:params:xml:ns:lost1"
264	            elementFormDefault="qualified">

266	   <xs:element name="findService">
267	     <xs:complexType>
268	       <xs:sequence>
269	         <xs:group ref="requestLocation"/>
270	         <xs:group ref="commonRequestPattern"/>
271	       </xs:sequence>
272	       <xs:attribute name="validateLocation" type="xs:boolean"/>
273	       <xs:attribute name="serviceBoundary">
274	         <xs:simpleType>
275	           <xs:restriction base="xs:token">
276	             <xs:enumeration value="reference"/>
277	             <xs:enumeration value="value"/>
278	           </xs:restriction>

280	         </xs:simpleType>
281	       </xs:attribute>
282	       <xs:attribute name="recursive" type="xs:boolean"/>
283	     </xs:complexType>
284	   </xs:element>

286	   <xs:element name="listServices">
287	     <xs:complexType>
288	       <xs:group ref="commonRequestPattern"/>
289	     </xs:complexType>
290	   </xs:element>

292	   <xs:element name="listServicesByLocation">
293	     <xs:complexType>
294	       <xs:sequence>
295	         <xs:group ref="requestLocation"/>
296	         <xs:group ref="commonRequestPattern"/>
297	       </xs:sequence>
298	       <xs:attribute name="recursive" type="xs:boolean"/>
299	     </xs:complexType>
300	   </xs:element>

302	   <xs:element name="getServiceBoundary">
303	     <xs:complexType>
304	       <xs:group ref="extensionPoint"/>
305	       <xs:attributeGroup ref="serviceBoundaryKey"/>
306	     </xs:complexType>
307	   </xs:element>

309	   <xs:element name="findServiceResponse">
310	     <xs:complexType>
311	       <xs:sequence>
312	         <xs:element ref="mapping" maxOccurs="unbounded"/>
313	         <xs:element ref="locationValidation" minOccurs="0"/>
314	         <xs:group ref="commonResponsePattern"/>
315	         <xs:group ref="locationUsed"/>
316	       </xs:sequence>
317	     </xs:complexType>
318	   </xs:element>

320	   <xs:element name="listServicesResponse">
321	     <xs:complexType>
322	       <xs:sequence>
323	         <xs:element ref="serviceList"/>
324	         <xs:group ref="commonResponsePattern"/>
325	       </xs:sequence>
326	     </xs:complexType>
327	   </xs:element>
328	   <xs:element name="listServicesByLocationResponse">
329	     <xs:complexType>
330	       <xs:sequence>
331	         <xs:element ref="serviceList"/>
332	         <xs:group ref="commonResponsePattern"/>
333	         <xs:group ref="locationUsed"/>
334	       </xs:sequence>
335	     </xs:complexType>
336	   </xs:element>

338	   <xs:element name="getServiceBoundaryResponse">
339	     <xs:complexType>
340	       <xs:sequence>
341	         <xs:group ref="serviceBoundary"/>
342	         <xs:group ref="commonResponsePattern"/>
343	       </xs:sequence>
344	     </xs:complexType>
345	   </xs:element>

347	   <xs:group name="commonRequestPattern">
348	     <xs:sequence>
349	       <xs:group ref="service"/>
350	       <xs:element ref="path" minOccurs="0"/>
351	       <xs:group ref="extensionPoint"/>
352	     </xs:sequence>
353	   </xs:group>

355	   <xs:group name="commonResponsePattern">
356	     <xs:sequence>
357	       <xs:element ref="warnings" minOccurs="0" maxOccurs="unbounded"/>
358	       <xs:element ref="path"/>
359	       <xs:group ref="extensionPoint"/>
360	     </xs:sequence>
361	   </xs:group>

363	   <xs:group name="requestLocation">
364	     <xs:sequence>
365	       <xs:element ref="location" maxOccurs="unbounded"/>
366	     </xs:sequence>
367	   </xs:group>

369	   <xs:element name="location">
370	     <xs:complexType>
371	       <xs:complexContent>
372	         <xs:extension base="locationInformation">
373	           <xs:attribute name="id" type="xs:token" use="required"/>
374	         </xs:extension>
375	       </xs:complexContent>

377	     </xs:complexType>
378	   </xs:element>

380	   <xs:complexType name="locationInformation">
381	     <xs:group ref="extensionPoint" maxOccurs="unbounded"/>
382	     <xs:attribute name="profile" type="xs:NMTOKEN"/>
383	   </xs:complexType>

385	   <xs:group name="serviceBoundary">
386	     <xs:sequence>
387	       <xs:element ref="serviceBoundary" maxOccurs="unbounded"/>
388	     </xs:sequence>
389	   </xs:group>

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

393	   <xs:element name="serviceBoundaryReference">
394	     <xs:complexType>
395	       <xs:group ref="extensionPoint"/>
396	       <xs:attributeGroup ref="source"/>
397	       <xs:attributeGroup ref="serviceBoundaryKey"/>
398	     </xs:complexType>
399	   </xs:element>

401	   <xs:attributeGroup name="serviceBoundaryKey">
402	     <xs:attribute name="key" type="xs:token" use="required"/>
403	   </xs:attributeGroup>

405	   <xs:element name="path">
406	     <xs:complexType>
407	       <xs:sequence>
408	         <xs:element ref="via" maxOccurs="unbounded"/>
409	       </xs:sequence>
410	     </xs:complexType>
411	   </xs:element>

413	   <xs:element name="via">
414	     <xs:complexType>
415	       <xs:group ref="extensionPoint"/>
416	       <xs:attributeGroup ref="source"/>
417	     </xs:complexType>
418	   </xs:element>

420	   <xs:group name="locationUsed">
421	     <xs:sequence>
422	       <xs:element ref="locationUsed" minOccurs="0"/>
423	     </xs:sequence>
424	   </xs:group>
425	   <xs:element name="locationUsed">
426	     <xs:complexType>
427	       <xs:attribute name="id" type="xs:token" use="required"/>
428	     </xs:complexType>
429	   </xs:element>

431	   <xs:attributeGroup name="expires">
432	     <xs:attribute name="expires" use="required">
433	       <xs:simpleType>
434	         <xs:union memberTypes="xs:dateTime">
435	           <xs:simpleType>
436	             <xs:restriction base="xs:token">
437	               <xs:enumeration value="NO-CACHE"/>
438	             </xs:restriction>
439	           </xs:simpleType>
440	           <xs:simpleType>
441	             <xs:restriction base="xs:token">
442	               <xs:enumeration value="NO-EXPIRATION"/>
443	             </xs:restriction>
444	           </xs:simpleType>
445	         </xs:union>
446	       </xs:simpleType>
447	     </xs:attribute>
448	   </xs:attributeGroup>

450	   <xs:simpleType name="qnameList">
451	     <xs:list itemType="xs:QName"/>
452	   </xs:simpleType>

454	   <xs:element name="mapping">
455	     <xs:complexType>
456	       <xs:sequence>
457	         <xs:element ref="displayName"
458	              minOccurs="0" maxOccurs="unbounded"/>
459	         <xs:group ref="service"/>
460	         <xs:choice minOccurs="0">
461	           <xs:group ref="serviceBoundary"/>
462	           <xs:element ref="serviceBoundaryReference"/>
463	         </xs:choice>
464	         <xs:element ref="uri"
465	              minOccurs="0" maxOccurs="unbounded"/>
466	         <xs:element ref="serviceNumber" minOccurs="0"/>
467	         <xs:group ref="extensionPoint"/>
468	       </xs:sequence>
469	       <xs:attributeGroup ref="expires"/>
470	       <xs:attribute name="lastUpdated" type="xs:dateTime"
471	             use="required"/>
472	       <xs:attributeGroup ref="source"/>
473	       <xs:attribute name="sourceId" type="xs:token"
474	             use="required"/>
475	       <xs:attributeGroup ref="message"/>
476	     </xs:complexType>
477	   </xs:element>

479	   <xs:element name="displayName">
480	     <xs:complexType>
481	       <xs:simpleContent>
482	         <xs:extension base="xs:string">
483	           <xs:attribute ref="xml:lang" use="required"/>
484	         </xs:extension>
485	       </xs:simpleContent>
486	     </xs:complexType>
487	   </xs:element>

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

491	   <xs:element name="serviceNumber">
492	     <xs:simpleType>
493	       <xs:restriction base="xs:token">
494	         <xs:pattern value="[0-9*#]+"/>
495	       </xs:restriction>
496	     </xs:simpleType>
497	   </xs:element>

499	   <xs:element name="locationValidation">
500	     <xs:complexType>
501	       <xs:sequence>
502	         <xs:element ref="valid" minOccurs="0"/>
503	         <xs:element ref="invalid" minOccurs="0"/>
504	         <xs:element ref="unchecked" minOccurs="0"/>
505	         <xs:group ref="extensionPoint"/>
506	       </xs:sequence>
507	     </xs:complexType>
508	   </xs:element>

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

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

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

516	   <xs:complexType name="exceptionContainer">
517	     <xs:sequence>
518	       <xs:choice minOccurs="0" maxOccurs="unbounded">
519	         <xs:element ref="badRequest"/>
520	         <xs:element ref="internalError"/>
521	         <xs:element ref="serviceSubstitution"/>
522	         <xs:element ref="defaultMappingReturned"/>
523	         <xs:element ref="forbidden"/>
524	         <xs:element ref="notFound"/>
525	         <xs:element ref="loop"/>
526	         <xs:element ref="serviceNotImplemented"/>
527	         <xs:element ref="serverTimeout"/>
528	         <xs:element ref="serverError"/>
529	         <xs:element ref="locationInvalid"/>
530	         <xs:element ref="locationProfileUnrecognized"/>
531	       </xs:choice>
532	       <xs:group ref="extensionPoint"/>
533	     </xs:sequence>
534	     <xs:attributeGroup ref="source"/>
535	   </xs:complexType>

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

539	   <xs:element name="warnings" type="exceptionContainer"/>

541	   <xs:complexType name="basicException">
542	     <xs:annotation>
543	       <xs:documentation>
544	         Exception pattern.
545	       </xs:documentation>
546	     </xs:annotation>
547	     <xs:group ref="extensionPoint"/>
548	     <xs:attributeGroup ref="message"/>
549	   </xs:complexType>

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

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

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

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

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

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

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

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

567	   <xs:element name="serverTimeout" type="basicException"/>
568	   <xs:element name="serverError" type="basicException"/>

570	   <xs:element name="SRSinvalid" type="basicException"/>

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

574	   <xs:element name="locationValidationUnavailable"
575	           type="basicException"/>

577	   <xs:element name="locationProfileUnrecognized">
578	           type="basicException"/>

580	   <xs:element name="redirect">
581	     <xs:complexType>
582	       <xs:group ref="extensionPoint"/>
583	       <xs:attribute name="target" type="appUniqueString"
584	           use="required"/>
585	       <xs:attributeGroup ref="source"/>
586	       <xs:attributeGroup ref="message"/>
587	     </xs:complexType>
588	   </xs:element>

590	   <xs:attributeGroup name="message">
591	     <xs:attribute name="message" type="xs:token"/>
592	     <xs:attribute ref="xml:lang"/>
593	   </xs:attributeGroup>

595	   <xs:group name="service">
596	     <xs:sequence>
597	       <xs:element ref="service" minOccurs="0"/>
598	     </xs:sequence>
599	   </xs:group>

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

603	   <xs:simpleType name="appUniqueString">
604	     <xs:restriction base="xs:token">
605	       <xs:pattern value="([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+"/>
606	     </xs:restriction>
607	   </xs:simpleType>

609	   <xs:attributeGroup name="source">
610	     <xs:attribute name="source" type="appUniqueString" use="required"/>
611	   </xs:attributeGroup>

613	   <xs:element name="serviceList">
614	     <xs:simpleType>
615	       <xs:list itemType="xs:anyURI"/>

617	     </xs:simpleType>
618	   </xs:element>

620	   <xs:group name="notLost">
621	     <xs:annotation>
622	       <xs:documentation>
623	         Any element not in the LoST namespace.
624	       </xs:documentation>
625	     </xs:annotation>
626	     <xs:choice>
627	       <xs:any namespace="##other" processContents="skip"/>
628	       <xs:any namespace="##local" processContents="skip"/>
629	     </xs:choice>
630	   </xs:group>

632	   <xs:group name="anyElement">
633	     <xs:annotation>
634	       <xs:documentation>
635	         A wildcard pattern for including any element
636	         from any other namespace.
637	       </xs:documentation>
638	     </xs:annotation>
639	     <xs:sequence>
640	       <xs:any processContents="skip"
641	           minOccurs="0" maxOccurs="unbounded"/>
642	     </xs:sequence>
643	   </xs:group>

645	   <xs:attributeGroup name="anyElement">
646	     <xs:annotation>
647	       <xs:documentation>
648	         A wildcard pattern for including any element
649	         from any other namespace.
650	       </xs:documentation>
651	     </xs:annotation>
652	     <xs:anyAttribute processContents="skip"/>
653	   </xs:attributeGroup>

655	   <xs:group name="extensionPoint">
656	     <xs:annotation>
657	       <xs:documentation>
658	         A point where future extensions
659	         (elements from other namespaces)
660	         can be added.
661	       </xs:documentation>
662	     </xs:annotation>
663	     <xs:sequence>
664	       <xs:group ref="notLost"
665	            minOccurs="0" maxOccurs="unbounded"/>
666	     </xs:sequence>
667	   </xs:group>

669	 </xs:schema>

671	8.  Extension XML Schema

673	   This schema provides the extension to the prior section schema for
674	   planned changes:

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

687	<!-- where -->
688	       <xs:group name="plannedChange">
689	           <xs:sequence>
690	              <xs:element ref="uri" type="xs:anyURI" />
691	              <xs:element ref=“invalidAsOf" type="xs:dateTime" />
692	              <xs:any namespace="##other" processContents="lax"
693	                 minOccurs="0" maxOccurs="unbounded"/>
694	           </xs:sequence>
695	        </xs:group>

697	<!-- extend the extensionPoint of commonResponsePattern in
698	                          findServiceResponse to include: -->
699	           <xs:atttribute name="asOf" type="xs:dateTime" minOccurs="0"/>
700	           <xs:element ref="ttl" type="expires" minOccurs="0" />

702	<!-- extend the extensionPoint of extensionContainer to include: -->
703	           <xs:element ref="uriNotStored"/>
704	<!-- where -->
705	           <xs:element name="uriNotStored" type="basicException"/>

707	</xs:schema>
708	9.  locationInvalidated Schema

710	   This schema defines the object used for the notification of
711	   (potential) invalidated location by the LoST server to a client that
712	   requested it.

714	   <?xml version="1.0" encoding="UTF-8"?>
715	   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
716	       xmlns="urn:ietf:params:xml:ns:lostLocationInvalidated1"
717	       targetNamespace="urn:ietf:params:xml:ns:lostLocationInvalidated1"
718	       elementFormDefault="qualified">
719	    <xs:element name="locationInvalidated">
720	      <xs:annotation>
721	        <xs:documentation>
722	          A point where future extensions
723	          (elements from other namespaces)
724	          can be added.
725	        </xs:documentation>
726	      </xs:annotation>
727	        <xs:complexType>
728	         <xs:sequence>
729	           <xs:group ref="notLost"
730	               minOccurs="0" maxOccurs="unbounded"/>
731	         </xs:sequence>
732	         <xs:attribute name="asOf" type="xs:dateTime"/>

734	   </xs:schema>

736	10.  Security Considerations

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

744	   The server is subject to abuse by clients because it is being asked
745	   to store something and may need to send data to an uncontrolled URI.
746	   Clients could request many URIs for the same location for example.
747	   The server MUST have policy that limits use of this mechanism by a
748	   given client.  If the policy is exceeded, the server returns the
749	   'uriNotStored' warning.  The server MUST validate that the content of
750	   the 'uri' attribute sent is syntactically valid and meets the 256
751	   bytes limit.  When sending the locationInvalidated object to the URI
752	   stored, the server MUST protect itself against common HTTP
753	   vulnerabilities.

755	   The mutual authentication between client and server is RECOMMENDED
756	   for both the initial <findService> operation that requests storing
757	   the URI and the sending of the 'locationInvalidated' object.  The
758	   server should be well known to the client, and its credential should
759	   be learned in a reliable way.  For example, a public safety system
760	   operating the LoST server may have a credential traceable to a well
761	   known Certificate Authority known to provide credentials for public
762	   safety agencies.  Many of the clients will be operated by local ISPs
763	   or other service providers where the server operator can reasonably
764	   obtain a good credential to use for the URI.  Where the server does
765	   not recognize the client, its policy MAY limit the use of this
766	   feature beyond what it would limit a client it recognized.

768	11.  IANA Considerations

770	11.1.  Replacement XML Schema Registration

772	      URI:  urn:ietf:params:xml:schema:lost3
773	      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
774	         (br@brianrosen.net).
775	      XML:
776	         BEGIN
777	         <?xml version="2.0"?>
778	         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
779	         "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
780	         <html xmlns="http://www.w3.org/1999/xhtml">
781	         <head>
782	         <meta http-equiv="content-type"
783	             content="text/html;charset=iso-8859-1"/>
784	         <title>LoST Namespace</title>
785	         </head>
786	         <body>
787	         <h1>Namespace for LoST</h1>
788	         <h2>urn:ietf:params:xml:ns:lost3</h2>
789	         <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
790	         RFC????</a>.</p>
791	         </body>
792	         </html>
793	         END

795	   The XML Schema is found in Section 7.

797	11.2.  Planned Change Extension XML Schema Registration
798	      URI:  urn:ietf:params:xml:schema:lostPlannedChange1
799	      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
800	         (br@brianrosen.net).
801	      XML:

803	      BEGIN
804	      <?xml version="2.0"?>
805	      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
806	        "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
807	      <html xmlns="http://www.w3.org/1999/xhtml">
808	      <head>
809	        <meta http-equiv="content-type"
810	              content="text/html;charset=iso-8859-1"/>
811	        <title>LoST Planned Change Namespace</title>
812	      </head>
813	      <body>
814	        <h1>Namespace for LoST </h1>
815	        <h2>urn:ietf:params:xml:ns:lostPlannedChange1</h2>
816	      <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
817	         RFC????</a>.</p>
818	      </body>
819	      </html>
820	      END

822	   The XML Schema is found in Section 8.

824	11.3.  locationInvalidated XML Schema Registration
825	   URI:  urn:ietf:params:xml:schema:lostLocationInvalidated1
826	   Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
827	     (br@brianrosen.net).
828	   XML:

830	   BEGIN
831	   <?xml version="2.0"?>
832	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
833	   "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
834	   <html xmlns="http://www.w3.org/1999/xhtml">
835	   <head>
836	   <meta http-equiv="content-type"
837	       content="text/html;charset=iso-8859-1"/>
838	   <title>LoST Location Invalided Namespace</title>
839	   </head>
840	   <body>
841	   <h1>Namespace for LoST Location Invalidated notification</h1>
842	   <h2>urn:ietf:params:xml:ns:lostLocationInvalidated1</h2>
843	   <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
844	   RFC????</a>.</p>
845	   </body>
846	   </html>
847	   END

849	   The XML Schema is found in Section 9.

851	12.  Normative References

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

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

863	Author's Address

865	   Brian Rosen
866	   470 Conrad Dr
867	   Mars, PA 16046
868	   United States of America

870	   Email: br@brianrosen.net