idnits 2.17.1 

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

  == 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 document date (11 October 2021) is 927 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 (~~), 2 warnings (==), 1 comment (--).

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


2	ecrit                                                           B. Rosen
3	Internet-Draft                                           11 October 2021
4	Updates: RFC5222 (if approved)
5	Intended status: Standards Track
6	Expires: 14 April 2022

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

11	Abstract

13	   This document defines an extension to the Location to Service
14	   Translation (LoST) protocol (RFC5222) that allows planned changes to
15	   the data to be handled smoothly.  This extension is only useful with
16	   the validation function of LoST.  It is beneficial for LoST
17	   validation clients to be aware of planned changes, as records that
18	   previously were valid may become invalid at a known future date, and
19	   new locations may become valid after the date.  This extension adds
20	   an element to the <findService> request: a date that allows the LoST
21	   client to request that the server perform validation as of the date
22	   specified.  It adds an optional Time-To-Live element to the response,
23	   which informs clients of the current expected lifetime of a
24	   validation.  It also adds a separate interface to the LoST server
25	   that allows a client to poll for planned changes.  Additionally, this
26	   document provides a conventional XML schema for LoST, as a backwards
27	   compatible alternative to the RelaxNG schema in RFC5222.

29	Status of This Memo

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

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

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

44	   This Internet-Draft will expire on 14 April 2022.

46	Copyright Notice

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

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

60	Table of Contents

62	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
63	   2.  Conventions used in this document . . . . . . . . . . . . . .   4
64	   3.  Planned Change Poll Interface . . . . . . . . . . . . . . . .   4
65	   4.  <plannedChange> element . . . . . . . . . . . . . . . . . . .   6
66	   5.  Time-To-Live (TTL) in Response  . . . . . . . . . . . . . . .   6
67	   6.  Replacement XML schema  . . . . . . . . . . . . . . . . . . .   7
68	   7.  Extension XML Schema  . . . . . . . . . . . . . . . . . . . .  15
69	   8.  plannedChangePoll Interface Description . . . . . . . . . . .  16
70	   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
71	   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
72	     10.1.  Replacement XML Schema Registration  . . . . . . . . . .  19
73	     10.2.  Planned Change Extension XML Schema Registration . . . .  20
74	   11. Normative References  . . . . . . . . . . . . . . . . . . . .  21
75	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

77	1.  Introduction

79	   Validation of civic locations involves dealing with data that may
80	   change over time.  A typical example is when a portion of a county or
81	   district that was not part of a municipality is "annexed" to a
82	   municipality.  Prior to the change, a Presence Information Data
83	   Format Location Object (PIDF-LO) specifying a civic location in the
84	   affected area would have a blank A3 element, or would contain some
85	   other value; after the change, a PIDF-LO specifying the same location
86	   would contain an A3 element set to the name of the municipality that
87	   annexed that part of the county/district.  This kind of annexation
88	   has an effective date and time (typically 00:00 on the first or last
89	   day of a month), known in advance.  Other kinds of changes may also
90	   occur, and these will almost always also have an effective date that
91	   is known in advance.

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

107	   This extension allows a LoST client to obtain from the LoST server
108	   sets of locations which may change.  It makes use of "partial
109	   location information" which is a set of location elements and values
110	   that, when compared against the client's location records, identify
111	   which of the clients records may change as a result of the planned
112	   change.  A set of such partial locations is termed a "ChangeSet".
113	   ChangeSets have an ID, and a date when the change is effective.  IDs
114	   are ordered.  The planned change interface is a REST/JSON interface
115	   that allows the client to poll the server using the last ID that it
116	   obtained from that server.  The response to the poll is a list of all
117	   the newer planned changes the server knows about beyond the ChangeSet
118	   whose ID was included in the poll.  The ID for the last ChangeSet in
119	   the returned list will be used by the client for the next poll.

121	   When a LIS receives a new ChangeSet, it may prepare one or more new
122	   records so that, at the precise planned event date and time, it may
123	   insert the new records into in its active database and delete the old
124	   records.  As part of preparing the new records in advance of the
125	   change, the LIS may use the "as of" date component of this extension
126	   to perform a LoST validation of the new record as of the effective
127	   date.

129	   The "asOf" date component of this extension in a <FindService>
130	   request allow a LIS to be prepared for and smoothly transition to
131	   planned changes, without the overhead and delay inherent in
132	   performing periodic revalidation of each location.  The notification
133	   URI allows a LIS to be alerted to planned changes, while the "as of"
134	   date allows the LIS to verify the validity of locations before they
135	   become active.

137	   In situations where it is not practical or advisable for the LIS to
138	   maintain a stable URI for each of its records, periodic revalidation
139	   can still be used to maintain the data in the LIS.  However, the LoST
140	   server should be able to influence the rate of such revalidation.

142	   For this purpose, this extension adds a Time to Live (TTL) attribute
143	   to the <findServiceResponse> which provides advice from the server to
144	   the LIS of when validation is suggested.

146	   There are quite a few implementations of LoST.  Experience with these
147	   implementations indicates that the RelaxNG schema is very difficult
148	   to deal with, both because many commonly used development tools don't
149	   support it, and development staff is often unfamiliar with it.
150	   Informal alternative schemas have been circulated, which is
151	   undesirable as they may not be in conformance with the RelaxNG schema
152	   in [RFC5222].  This document provides an XML schema that replaces the
153	   RelaxNG schema.  It can be used by any implementation interchangeably
154	   with the RelaxNG schema.

156	2.  Conventions used in this document

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

162	   "Server" in this document refers to the LoST server and "Client" is
163	   the LoST client, even when the server is performing an operation on
164	   the client.

166	3.  Planned Change Poll Interface

168	   This document defines a new interface to the LoST server.  The
169	   interface has three entry points.  One, Versions, returns the current
170	   version(s) the interface supports.  This allows the interface to
171	   evolve over time.  Another entry point, PlannedChangePoll, is a poll.
172	   The poll returns a list of changeSetIds which identify ChangeSet
173	   objects.  The third, GetChangeSet, accepts a changeSetId and returns
174	   the ChangeSet object which contains the identifier (changeSetId), a
175	   date (changeSetEffective) and an array of partial locations.  A
176	   partial location is an array of location information element name and
177	   value pairs.  The client compares the location elements with its
178	   records.  For each of the clients records where all of the location
179	   elements provided in the partial location have the same values as
180	   those in the partial location, that client record may be affected by
181	   the planned change.  The client's records may have other location
182	   elements, but those are not considered in the comparison.  So, for
183	   example, a partial location may have a Country, A1, A2, A3 and A4
184	   location elements, which means that any address with that Country,
185	   A1, A2, A3 and A4 values may be affected by the planned change
186	   regardless of street name and number.  As another example, a partial
187	   location with Country, A1, A2, A3, A4, RD and POD but not HN means
188	   any address number on the specified street.

190	   The changeSetId is string, which the server maintains as an ordered
191	   list of changeSetIds.  The id itself may not show the ordering.  For
192	   example, it could be a hashed timestamp, or a hashed sequence number.
193	   Given a changeSetId returned by it in a prior poll, the server can
194	   identify which ChangeSets it has that come after, in order, after the
195	   one with the proffered changeSetId.  A new client does not know any
196	   ids, or a client may lose the id that it had.  The client would poll
197	   omitting the changeSetId in the poll query, and it response, the
198	   server returns all the ChangeSets it knows about.  The effective date
199	   of a ChangeSet returned by the server need not always be in the
200	   future.  Tardy clients may not keep up.  On the other hand, the
201	   server is not obligated to keep change sets whoose changeSetEffective
202	   date has past for more than some arbitrary time.  A 12 month time
203	   period may be appropriate for a server whose service area doesn't
204	   have many changes, where a 3 month time period may be needed in a
205	   fast changing service area where many changes occur regularly.  A
206	   tardy client in a fast changing environment may recieve a large
207	   number of ChangSets in response to a poll.

209	   Polls are expected every few minutes.  A new client omits the ID in
210	   its first poll, and the server responds with all the changeSetsIds
211	   that it knows about.  Thereafter, the client retains the last
212	   changeSetId in its most recent poll and uses that in the next poll.
213	   If the response to that poll is no changeSetIds, it means the
214	   changeSetId the client has is the latest change the server knows
215	   about, and that same changeSetId will be used in subsequent polls
216	   until the server returns a new one.

218	   The version mechanism returns a list of versions of the web service
219	   it supports.  This document describes version 1.0.  Versions are
220	   described as a major version, the period "." and a minor version,
221	   where major and minor versions are integers.  A backwards compatible
222	   change within a major version MAY increment only the minor version
223	   number.  A non-backwards compatible change MUST increment the major
224	   version number.  To achieve backwards compatibility, implementations
225	   MUST ignore any object members they do not implement.  Minor version
226	   definitions SHALL only add objects, non-required members of existing
227	   objects, and non-mandatory-to use functions and SHALL NOT delete any
228	   objects, members of objects or functions.  This means an
229	   implementation of a specific major version and minor version is
230	   backwards compatible with all minor versions of the major version.
231	   The versions mechanism returns an array of supported versions, one
232	   for each major version supported, with the minor version listed being
233	   the highest supported minor version.

235	4.  <plannedChange> element

237	   This document defines a new element in the <findService> request
238	   called "plannedChange".  This element contains an attribute: 'asOf'.
239	   The 'asOf' attribute contains a date and time in dateTime format with
240	   a required timezone.  The server validates the location in the
241	   request as of the date and time specified, taking into account
242	   planned changes.  This allows a client to verify that it can make
243	   changes in the LIS commensurate with changes in the LoST server by
244	   validating locations in advance of a change.

246	5.  Time-To-Live (TTL) in Response

248	   This extension adds the 'ttl' element to the <findServiceResponse>.
249	   The 'ttl'; element contains a date and time after which the client
250	   may wish to revalidate the location at the server.  A server MAY add
251	   this attribute to the response if validation is requested.  This
252	   element takes the form of the 'expires' attribute pattern of
253	   [RFC5222], which allows the values "NO-CACHE" or "NO-EXPIRATION" to
254	   be returned instead of a dateTime value.  However, for the 'ttl';
255	   attribute "NO-CACHE" has no meaning and MUST NOT be returned.  "NO-
256	   EXPIRATION" means the server does not have a suggested revalidation
257	   period.

259	   Selecting a revalidation interval is a complex balancing of
260	   timeliness, server load, stability of the underlying data, and policy
261	   of the LoST server.  Too short, and load on the server may overwhelm
262	   it.  Too long and invalid data may persist in the server for
263	   unacceptable lengths of time.  The URI notification mechanism
264	   provides timely notice to coordinate changes, but even with it, it is
265	   often advisable to revalidate data eventually.

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

275	   When a planned change is made, typically the TTL value for the
276	   affected records is lowered, so that revalidation is forced soon
277	   after the change is implemented.  It is not advisable to set the
278	   expiration precisely at the planned change time if a large number of
279	   records will be changed, since that would cause a large spike in
280	   traffic at the change time.  Rather, the expiration time should have
281	   a random additional time added to it to spread out the load.

283	6.  Replacement XML schema

285	   This schema is an alternative to The Relax NG schema in [RFC5222].
286	   Future extensions to LoST are exected to use this schema as the base
287	   for the extensions, rather than the Relax NG schema.  Existing
288	   extensions described using the Relax NG schema continue to be valid.

290	 <?xml version="1.0" encoding="UTF-8"?>
291	 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
292	            xmlns="urn:ietf:params:xml:ns:lost1"
293	            targetNamespace="urn:ietf:params:xml:ns:lost1"
294	            elementFormDefault="qualified">

296	   <xs:element name="findService">
297	     <xs:complexType>
298	       <xs:sequence>
299	         <xs:group ref="requestLocation"/>
300	         <xs:group ref="commonRequestPattern"/>
301	       </xs:sequence>
302	       <xs:attribute name="validateLocation" type="xs:boolean"/>
303	       <xs:attribute name="serviceBoundary">
304	         <xs:simpleType>
305	           <xs:restriction base="xs:token">
306	             <xs:enumeration value="reference"/>
307	             <xs:enumeration value="value"/>
308	           </xs:restriction>
309	         </xs:simpleType>
310	       </xs:attribute>
311	       <xs:attribute name="recursive" type="xs:boolean"/>
312	     </xs:complexType>
313	   </xs:element>

315	   <xs:element name="listServices">
316	     <xs:complexType>
317	       <xs:group ref="commonRequestPattern"/>
318	     </xs:complexType>
319	   </xs:element>

321	   <xs:element name="listServicesByLocation">
322	     <xs:complexType>
323	       <xs:sequence>
324	         <xs:group ref="requestLocation"/>
325	         <xs:group ref="commonRequestPattern"/>
326	       </xs:sequence>
327	       <xs:attribute name="recursive" type="xs:boolean"/>
328	     </xs:complexType>
329	   </xs:element>
330	   <xs:element name="getServiceBoundary">
331	     <xs:complexType>
332	       <xs:group ref="extensionPoint"/>
333	       <xs:attributeGroup ref="serviceBoundaryKey"/>
334	     </xs:complexType>
335	   </xs:element>

337	   <xs:element name="findServiceResponse">
338	     <xs:complexType>
339	       <xs:sequence>
340	         <xs:element ref="mapping" maxOccurs="unbounded"/>
341	         <xs:element ref="locationValidation" minOccurs="0"/>
342	         <xs:group ref="commonResponsePattern"/>
343	         <xs:group ref="locationUsed"/>
344	       </xs:sequence>
345	     </xs:complexType>
346	   </xs:element>

348	   <xs:element name="listServicesResponse">
349	     <xs:complexType>
350	       <xs:sequence>
351	         <xs:element ref="serviceList"/>
352	         <xs:group ref="commonResponsePattern"/>
353	       </xs:sequence>
354	     </xs:complexType>
355	   </xs:element>

357	   <xs:element name="listServicesByLocationResponse">
358	     <xs:complexType>
359	       <xs:sequence>
360	         <xs:element ref="serviceList"/>
361	         <xs:group ref="commonResponsePattern"/>
362	         <xs:group ref="locationUsed"/>
363	       </xs:sequence>
364	     </xs:complexType>
365	   </xs:element>

367	   <xs:element name="getServiceBoundaryResponse">
368	     <xs:complexType>
369	       <xs:sequence>
370	         <xs:group ref="serviceBoundary"/>
371	         <xs:group ref="commonResponsePattern"/>
372	       </xs:sequence>
373	     </xs:complexType>
374	   </xs:element>

376	   <xs:group name="commonRequestPattern">
377	     <xs:sequence>
378	       <xs:group ref="service"/>
379	       <xs:element ref="path" minOccurs="0"/>
380	       <xs:group ref="extensionPoint"/>
381	     </xs:sequence>
382	   </xs:group>

384	   <xs:group name="commonResponsePattern">
385	     <xs:sequence>
386	       <xs:element ref="warnings" minOccurs="0" maxOccurs="unbounded"/>
387	       <xs:element ref="path"/>
388	       <xs:group ref="extensionPoint"/>
389	     </xs:sequence>
390	   </xs:group>

392	   <xs:group name="requestLocation">
393	     <xs:sequence>
394	       <xs:element ref="location" maxOccurs="unbounded"/>
395	     </xs:sequence>
396	   </xs:group>

398	   <xs:element name="location">
399	     <xs:complexType>
400	       <xs:complexContent>
401	         <xs:extension base="locationInformation">
402	           <xs:attribute name="id" type="xs:token" use="required"/>
403	         </xs:extension>
404	       </xs:complexContent>
405	     </xs:complexType>
406	   </xs:element>

408	   <xs:complexType name="locationInformation">
409	     <xs:group ref="extensionPoint" maxOccurs="unbounded"/>
410	     <xs:attribute name="profile" type="xs:NMTOKEN"/>
411	   </xs:complexType>

413	   <xs:group name="serviceBoundary">
414	     <xs:sequence>
415	       <xs:element ref="serviceBoundary" maxOccurs="unbounded"/>
416	     </xs:sequence>
417	   </xs:group>

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

421	   <xs:element name="serviceBoundaryReference">
422	     <xs:complexType>
423	       <xs:group ref="extensionPoint"/>
424	       <xs:attributeGroup ref="source"/>
425	       <xs:attributeGroup ref="serviceBoundaryKey"/>

427	     </xs:complexType>
428	   </xs:element>

430	   <xs:attributeGroup name="serviceBoundaryKey">
431	     <xs:attribute name="key" type="xs:token" use="required"/>
432	   </xs:attributeGroup>

434	   <xs:element name="path">
435	     <xs:complexType>
436	       <xs:sequence>
437	         <xs:element ref="via" maxOccurs="unbounded"/>
438	       </xs:sequence>
439	     </xs:complexType>
440	   </xs:element>

442	   <xs:element name="via">
443	     <xs:complexType>
444	       <xs:group ref="extensionPoint"/>
445	       <xs:attributeGroup ref="source"/>
446	     </xs:complexType>
447	   </xs:element>

449	   <xs:group name="locationUsed">
450	     <xs:sequence>
451	       <xs:element ref="locationUsed" minOccurs="0"/>
452	     </xs:sequence>
453	   </xs:group>

455	   <xs:element name="locationUsed">
456	     <xs:complexType>
457	       <xs:attribute name="id" type="xs:token" use="required"/>
458	     </xs:complexType>
459	   </xs:element>

461	   <xs:attributeGroup name="expires">
462	     <xs:attribute name="expires" use="required">
463	       <xs:simpleType>
464	         <xs:union memberTypes="xs:dateTime">
465	           <xs:simpleType>
466	             <xs:restriction base="xs:token">
467	               <xs:enumeration value="NO-CACHE"/>
468	             </xs:restriction>
469	           </xs:simpleType>
470	           <xs:simpleType>
471	             <xs:restriction base="xs:token">
472	               <xs:enumeration value="NO-EXPIRATION"/>
473	             </xs:restriction>
474	           </xs:simpleType>

476	         </xs:union>
477	       </xs:simpleType>
478	     </xs:attribute>
479	   </xs:attributeGroup>

481	   <xs:simpleType name="qnameList">
482	     <xs:list itemType="xs:QName"/>
483	   </xs:simpleType>

485	   <xs:element name="mapping">
486	     <xs:complexType>
487	       <xs:sequence>
488	         <xs:element ref="displayName"
489	              minOccurs="0" maxOccurs="unbounded"/>
490	         <xs:group ref="service"/>
491	         <xs:choice minOccurs="0">
492	           <xs:group ref="serviceBoundary"/>
493	           <xs:element ref="serviceBoundaryReference"/>
494	         </xs:choice>
495	         <xs:element ref="uri"
496	              minOccurs="0" maxOccurs="unbounded"/>
497	         <xs:element ref="serviceNumber" minOccurs="0"/>
498	         <xs:group ref="extensionPoint"/>
499	       </xs:sequence>
500	       <xs:attributeGroup ref="expires"/>
501	       <xs:attribute name="lastUpdated" type="xs:dateTime"
502	             use="required"/>
503	       <xs:attributeGroup ref="source"/>
504	       <xs:attribute name="sourceId" type="xs:token"
505	             use="required"/>
506	       <xs:attributeGroup ref="message"/>
507	     </xs:complexType>
508	   </xs:element>

510	   <xs:element name="displayName">
511	     <xs:complexType>
512	       <xs:simpleContent>
513	         <xs:extension base="xs:string">
514	           <xs:attribute ref="xml:lang" use="required"/>
515	         </xs:extension>
516	       </xs:simpleContent>
517	     </xs:complexType>
518	   </xs:element>

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

522	   <xs:element name="serviceNumber">
523	     <xs:simpleType>
524	       <xs:restriction base="xs:token">
525	         <xs:pattern value="[0-9*#]+"/>
526	       </xs:restriction>
527	     </xs:simpleType>
528	   </xs:element>

530	   <xs:element name="locationValidation">
531	     <xs:complexType>
532	       <xs:sequence>
533	         <xs:element ref="valid" minOccurs="0"/>
534	         <xs:element ref="invalid" minOccurs="0"/>
535	         <xs:element ref="unchecked" minOccurs="0"/>
536	         <xs:group ref="extensionPoint"/>
537	       </xs:sequence>
538	     </xs:complexType>
539	   </xs:element>

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

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

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

547	   <xs:complexType name="exceptionContainer">
548	     <xs:sequence>
549	       <xs:choice minOccurs="0" maxOccurs="unbounded">
550	         <xs:element ref="badRequest"/>
551	         <xs:element ref="internalError"/>
552	         <xs:element ref="serviceSubstitution"/>
553	         <xs:element ref="defaultMappingReturned"/>
554	         <xs:element ref="forbidden"/>
555	         <xs:element ref="notFound"/>
556	         <xs:element ref="loop"/>
557	         <xs:element ref="serviceNotImplemented"/>
558	         <xs:element ref="serverTimeout"/>
559	         <xs:element ref="serverError"/>
560	         <xs:element ref="locationInvalid"/>
561	         <xs:element ref="locationProfileUnrecognized"/>
562	       </xs:choice>
563	       <xs:group ref="extensionPoint"/>
564	     </xs:sequence>
565	     <xs:attributeGroup ref="source"/>
566	   </xs:complexType>

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

570	   <xs:element name="warnings" type="exceptionContainer"/>
571	   <xs:complexType name="basicException">
572	     <xs:annotation>
573	       <xs:documentation>
574	         Exception pattern.
575	       </xs:documentation>
576	     </xs:annotation>
577	     <xs:group ref="extensionPoint"/>
578	     <xs:attributeGroup ref="message"/>
579	   </xs:complexType>

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

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

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

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

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

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

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

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

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

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

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

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

605	   <xs:element name="locationValidationUnavailable"
606	           type="basicException"/>

608	   <xs:element name="locationProfileUnrecognized">
609	           type="basicException"/>

611	   <xs:element name="redirect">
612	     <xs:complexType>
613	       <xs:group ref="extensionPoint"/>
614	       <xs:attribute name="target" type="appUniqueString"
615	           use="required"/>
616	       <xs:attributeGroup ref="source"/>
617	       <xs:attributeGroup ref="message"/>
618	     </xs:complexType>

620	   </xs:element>

622	   <xs:attributeGroup name="message">
623	     <xs:attribute name="message" type="xs:token"/>
624	     <xs:attribute ref="xml:lang"/>
625	   </xs:attributeGroup>

627	   <xs:group name="service">
628	     <xs:sequence>
629	       <xs:element ref="service" minOccurs="0"/>
630	     </xs:sequence>
631	   </xs:group>

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

635	   <xs:simpleType name="appUniqueString">
636	     <xs:restriction base="xs:token">
637	       <xs:pattern value="([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+"/>
638	     </xs:restriction>
639	   </xs:simpleType>

641	   <xs:attributeGroup name="source">
642	     <xs:attribute name="source" type="appUniqueString" use="required"/>
643	   </xs:attributeGroup>

645	   <xs:element name="serviceList">
646	     <xs:simpleType>
647	       <xs:list itemType="xs:anyURI"/>
648	     </xs:simpleType>
649	   </xs:element>

651	   <xs:group name="notLost">
652	     <xs:annotation>
653	       <xs:documentation>
654	         Any element not in the LoST namespace.
655	       </xs:documentation>
656	     </xs:annotation>
657	     <xs:choice>
658	       <xs:any namespace="##other" processContents="skip"/>
659	       <xs:any namespace="##local" processContents="skip"/>
660	     </xs:choice>
661	   </xs:group>

663	   <xs:group name="anyElement">
664	     <xs:annotation>
665	       <xs:documentation>
666	         A wildcard pattern for including any element
667	         from any other namespace.

669	       </xs:documentation>
670	     </xs:annotation>
671	     <xs:sequence>
672	       <xs:any processContents="skip"
673	           minOccurs="0" maxOccurs="unbounded"/>
674	     </xs:sequence>
675	   </xs:group>

677	   <xs:attributeGroup name="anyElement">
678	     <xs:annotation>
679	       <xs:documentation>
680	         A wildcard pattern for including any element
681	         from any other namespace.
682	       </xs:documentation>
683	     </xs:annotation>
684	     <xs:anyAttribute processContents="skip"/>
685	   </xs:attributeGroup>

687	   <xs:group name="extensionPoint">
688	     <xs:annotation>
689	       <xs:documentation>
690	         A point where future extensions
691	         (elements from other namespaces)
692	         can be added.
693	       </xs:documentation>
694	     </xs:annotation>
695	     <xs:sequence>
696	       <xs:group ref="notLost"
697	            minOccurs="0" maxOccurs="unbounded"/>
698	     </xs:sequence>
699	   </xs:group>

701	 </xs:schema>

703	7.  Extension XML Schema

705	   This schema provides the extension to the prior section schema for
706	   planned changes:

708	 <?xml version="1.0" encoding="UTF-8"?>
709	 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
710	            xmlns="urn:ietf:params:xml:ns:lostPlannedChange1"
711	            targetNamespace="urn:ietf:params:xml:ns:lostPlannedChange1"
712	            elementFormDefault="qualified">
713	      <!-- Import base Lost -->
714	      <xs:import namespace="urn:ietf:params:xml:ns:lost1"/>
715	 <!-- extend the extensionPoint of commonRequestPattern of findService
716	                                                        to include:  -->
717	         xs:group ref="plannedChange" minOccurs="1"/>

719	 <!-- where -->
720	        <xs:group name="plannedChange">
721	            <xs:sequence>
722	               <xs:element ref="asOf" type="xs:dateTime" minOccurs=
723	               "1"/>
724	               <xs:any namespace="##other" processContents="lax"
725	                  minOccurs="0" maxOccurs="unbounded"/>
726	            </xs:sequence>
727	         </xs:group>

729	 <!-- extend the extensionPoint of commonResponsePattern in
730	                           findServiceResponse to include: -->
731	            <xs:element ref="ttl" type="expires" minOccurs="0" />

733	 <!-- extend the extensionPoint of extensionContainer to include: -->
734	            <xs:element ref="uriNotStored"/>
735	 <!-- where -->
736	            <xs:element name="uriNotStored" type="basicException"/>

738	 </xs:schema>

740	8.  plannedChangePoll Interface Description

742	            openapi: 3.0.1
743	        info:
744	          title: LoST plannedChange
745	          version: "1.0"
746	        servers:
747	          - url: http://localhost/LoST/v1
748	        paths:
749	          /PlannedChangePoll:
750	            get:
751	              summary: Get a list of planned changeSetIds
752	              operationId: getPlannedChangeIds
753	              responses:

755	                '200':
756	                  description: Planned Changes
757	                  content:
758	                    application/json:
759	                      schema:
760	                        $ref: '#/components/schemas/PlannedChangeIdList'
761	          /GetChangeSet:
762	            get:
763	              summary: Get a changeSet
764	              operationId: getChangeSet
765	              parameters:
766	                - in: query
767	                  name: changeSetId
768	                  schema:
769	                    type: string
770	                  description: Id of a changeSet
771	              responses:
772	                '200':
773	                  description: changeSet object
774	                  content:
775	                    application/json:
776	                      schema:
777	                        $ref: '#/components/schemas/ChangeSet'
778	          /Versions:
779	            servers:
780	              - url: https://api.example.com/rum
781	                description: Override base path for Versions query
782	            get:
783	              summary: Retrieves all supported versions
784	              operationId: RetrieveVersions
785	              responses:
786	                '200':
787	                  description: Versions supported
788	                  content:
789	                    application/json:
790	                      schema:
791	                        $ref: '#/components/schemas/VersionsArray'
792	        components:
793	          schemas:
794	            PlannedChangeIdList:
795	              type: array
796	              items:
797	                type: string
798	            ChangeSet:
799	              type: object
800	              properties:
801	                changeSetId:
802	                  type: string
803	                  description: Id of the changeSet
804	                changeSetEffective:
805	                  type: string
806	                  format: datetime
807	                  description: date and time change will come into
808	                     effect in dateTime format with a required timezone
809	                partialLocationList:
810	                  type: array
811	                  items:
812	                    type: object
813	                    properties:
814	                      caType:
815	                        type: string
816	                        description: CAtype name from IANA registry
817	                      value:
818	                        type: string
819	                        description: value for this caType
820	            VersionsArray:
821	              type: object
822	              required:
823	                - versions
824	              properties:
825	                versions:
826	                  type: array
827	                  items:
828	                    type: object
829	                    required:
830	                      - major
831	                      - minor
832	                    properties:
833	                      major:
834	                        type: integer
835	                        format: int32
836	                        description: Version major number
837	                      minor:
838	                        type: integer
839	                        format: int32
840	                        description: Version minor number

842	9.  Security Considerations

844	   As an extension to LoST, this document inherits the security issues
845	   raised in [RFC5222].  The server could be tricked into storing a
846	   malicious URI which, when sent the revalidateLocation object could
847	   trigger something untoward.  The server MUST NOT accept any data from
848	   the client in response to POSTing the revalidateLocation.

850	   The server is subject to abuse by clients because it is being asked
851	   to store something and may need to send data to an uncontrolled URI.
852	   Clients could request many URIs for the same location, for example.
853	   The server MUST have policy that limits use of this mechanism by a
854	   given client.  If the policy is exceeded, the server returns the
855	   <uriNotStored> warning.  The server MUST validate that the content of
856	   the 'uri' attribute sent is syntactically valid and meets the 256
857	   bytes limit.  When sending the <revalidateLocation> object to the URI
858	   stored, the server MUST protect itself against common HTTP
859	   vulnerabilities.

861	   The mutual authentication between client and server is RECOMMENDED
862	   for both the initial <findServiceRequest> operation that requests
863	   storing the URI and the sending of the <revalidateLocation> object.
864	   The server should be well known to the client, and its credential
865	   should be learned in a reliable way.  For example, a public safety
866	   system operating the LoST server may have a credential traceable to a
867	   well known Certificate Authority known to provide credentials for
868	   public safety agencies.  Clients may be operated by local ISPs or
869	   other service providers that can reasonably obtain a good credential
870	   to use for the server side of the LoST server's POST transaction
871	   using the URI.  Where the loST server does not recognize the client,
872	   its policy MAY limit the use of this feature beyond what it would
873	   limit a client it recognizes.

875	10.  IANA Considerations

877	10.1.  Replacement XML Schema Registration
878	      URI:  urn:ietf:params:xml:schema:lost3
879	      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
880	         (br@brianrosen.net).
881	      XML:
882	         BEGIN
883	         <?xml version="2.0"?>
884	         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
885	         "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
886	         <html xmlns="http://www.w3.org/1999/xhtml">
887	         <head>
888	         <meta http-equiv="content-type"
889	             content="text/html;charset=iso-8859-1"/>
890	         <title>LoST Namespace</title>
891	         </head>
892	         <body>
893	         <h1>Namespace for LoST</h1>
894	         <h2>urn:ietf:params:xml:ns:lost3</h2>
895	         <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
896	         RFC????</a>.</p>
897	         </body>
898	         </html>
899	         END

901	   The XML Schema is found in Section 6.

903	10.2.  Planned Change Extension XML Schema Registration
904	      URI:  urn:ietf:params:xml:schema:lostPlannedChange1
905	      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
906	         (br@brianrosen.net).
907	      XML:

909	      BEGIN
910	      <?xml version="2.0"?>
911	      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
912	        "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
913	      <html xmlns="http://www.w3.org/1999/xhtml">
914	      <head>
915	        <meta http-equiv="content-type"
916	              content="text/html;charset=iso-8859-1"/>
917	        <title>LoST Planned Change Namespace</title>
918	      </head>
919	      <body>
920	        <h1>Namespace for LoST </h1>
921	        <h2>urn:ietf:params:xml:ns:lostPlannedChange1</h2>
922	      <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
923	         RFC????</a>.</p>
924	      </body>
925	      </html>
926	      END

928	   The XML Schema is found in Section 7.

930	11.  Normative References

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

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

942	Author's Address

944	   Brian Rosen
945	   470 Conrad Dr
946	   Mars, PA 16046
947	   United States of America

949	   Email: br@brianrosen.net