idnits 2.17.1 draft-rosen-ecrit-lost-return-li-00.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 (March 29, 2011) is 4748 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft Neustar 4 Intended status: Standards Track March 29, 2011 5 Expires: September 30, 2011 7 Returning a Location Information in a Location to Service Translation 8 query 9 draft-rosen-ecrit-lost-return-li-00 11 Abstract 13 This document defines an extension to LoST (RFC5222) to permit a 14 location information to be returned in a findservice response. When 15 the validation is requested in the findservice request, the location 16 information supplied in the request may have enough valid address 17 components (CAtypes) to be considered valid, but the LoST server may 18 wish to return address components CAtypes not found in the query. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 30, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Conventions used in this document . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. responseLocation . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 6.1. XML Schema Registration . . . . . . . . . . . . . . . . . . 5 61 6.2. LoST Extension to Return LI Relax NG Schema 62 Registration . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.3. LoST Extension to return LI Namespace Registration . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 67 1. Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 2. Overview 75 This document describes an extension to LoST [RFC5222], to allow 76 location information to be returned in a . When 77 requesting validation, the location information in the 78 request may contain enough CAtypes to be considered valid. The LoST 79 server may have all of the address components for the location. As 80 an example, the query may contain a PC, postal code, but may not 81 contain A1, A2 or A3 CAtypes. The street name and PC may be 82 sufficient to locate the address specified in the request and thus be 83 considered. It may be helpful to downstream entities to have the 84 A1-A3 components, and the LoST server could supply them. However, 85 [RFC5222] does not have a way for location information to be returned 86 in the . This document adds the possibility to 87 include a element to the message. 89 3. responseLocation 91 This document defines a new element which MAY be 92 included in a when validation is requested. It 93 MUST NOT be used in any other request or response. The Location 94 Information in the response MUST contain all of the location 95 information in the request and MAY contain any additional CAtypes 96 that refer to the same location specified in the request. 98 4. Relax NG Schema 100 This section provides the Relax NG schema for an extension to include 101 the in the in the compact form. The 102 verbose form is included in Appendix A. 104 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 105 default namespace ns1 = "urn:ietf:params:xml:ns:lostRLI" 107 ## 108 ## Extensions to the Location-to-Service Translation (LoST) 109 ## Protocol 111 ## 112 ## LoST Extensions to optionally return a in 113 ## 114 ## 115 start = 116 responseLocation 118 ## 119 ## findServiceResponse 120 ## 121 div { 122 findServiceResponse = 123 extensionPoint+, 124 attribute profile { xsd:NMTOKEN }? 125 } 127 ## 128 ## Location in Responses 129 ## 130 div { 131 responseLocation = 132 element location { 133 attribute id { xsd:token }, 134 locationInformation 135 }+ 136 } 138 ## 139 ## Patterns for inclusion of elements from schemas in 140 ## other namespaces. 141 ## 142 div { 144 ## 145 ## Any element not in the LoST Extensions 146 ## namespace. 147 ## 148 notLostRP = element * - (ns1:* | ns1:*) { anyElement } 150 ## 151 ## A wildcard pattern for including any element 152 ## from any other namespace. 153 ## 154 anyElement = 155 (element * { anyElement } 156 | attribute * { text } 157 | text)* 159 ## 160 ## A point where future extensions 161 ## (elements from other namespaces) 162 ## can be added. 163 ## 164 extensionPoint = notLostRP* 165 } 167 Figure 1: Relax NG Schema 169 5. Security Considerations 171 Although the input to the LoST request may be valid, however the LoST 172 server determines what valid is, the requester may not actually 173 understand where that is. This extension returns more location 174 information that the requester may not have had which may reveal more 175 about the location. While this may be very desirable for, e.g. an 176 emergency call, it may not be as desirable for other services. The 177 LoST server implementation should consider the risk of releasing more 178 detail verses the value in doing so. Generally, we do not believe 179 this is a significant problem as the requester must have enough 180 location information to be considered valid, which in most cases is 181 enough to uniquely locate the address. Providing more CAtypes 182 generally doesn't actually reveal anything more. 184 6. IANA Considerations 186 6.1. XML Schema Registration 188 This section registers an XML schema as per the procedures in 189 [RFC3688]. 191 URI: urn:ietf:params:xml:schema:lostRLI 193 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 194 Brian Rosen (br@brianrosen.net). 196 The XML for this schema can be found as the entirety of Section 7 197 of this document. 199 6.2. LoST Extension to Return LI Relax NG Schema Registration 201 URI: urn:ietf:params:xml:schema:lostRLI 203 Registrant Contact: Brian Rosen (br@brianrosen.net) 205 Relax NG Schema: The Relax NG schema to be registered is contained in 206 Section 4. Its first line is 208 default namespace ns1 = "urn:ietf:params:xml:ns:lostRLI" 210 and its last line is 212 } 214 6.3. LoST Extension to return LI Namespace Registration 216 URI: urn:ietf:params:xml:ns:lost1:ext 218 Registrant Contact: Brian Rosen (br@brianrosen.net) 220 XML: 222 BEGIN 223 224 226 227 228 230 LoST Extension to Return LI Namespace 231 232 233

Namespace for LoST Extension to return LI

234

urn:ietf:params:xml:ns:lostRLI

235

See 236 RFCXXXX.

237 238 239 END 240 243 END 245 7. Acknowledgements 247 This work arose from discussions held within the NENA Long Term 248 Development work group. 250 8. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 256 Tschofenig, "LoST: A Location-to-Service Translation 257 Protocol", RFC 5222, August 2008. 259 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 260 January 2004. 262 Author's Address 264 Brian Rosen 265 Neustar 266 470 Conrad Dr 267 Mars, PA 16046 268 US 270 EMail: br@brianrosen.net