idnits 2.17.00 (12 Aug 2021) /tmp/idnits55447/draft-robins-ecrit-sub-services-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 284. 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 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2008) is 5071 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) == Missing Reference: 'LOST' is mentioned on line 199, but not defined == Unused Reference: 'I-D.ietf-ecrit-lost' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-pdif-lo-profile' is defined on line 220, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-lost has been published as RFC 5222 == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. George 3 Internet-Draft Q. Sun 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 2, 2009 July 1, 2008 7 Location-to-Service Translation Protocol (LoST) Sub-Services 8 draft-robins-ecrit-sub-services-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 2, 2009. 35 Abstract 37 This document describes, how a LoST client can ask LoST server for 38 the list of sub services that it supports, and to incorporate 39 additional information about the service provider in response. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Terminology used in this document . . . . . . . . . . . . . . . 3 45 3. LoST extension . . . . . . . . . . . . . . . . . . . . . . . . 3 46 4. sub-service . . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 5. sub-service in Request . . . . . . . . . . . . . . . . . . . . 4 48 6. sub-service in Response . . . . . . . . . . . . . . . . . . . . 5 49 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 50 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 51 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 53 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Intellectual Property and Copyright Statements . . . . . . . . . . 8 57 1. Introduction 59 The Location-to-Service Translation (LoST) protocol [LOST] maps 60 service identifiers (URNs) and civic or geospatial information to 61 service URIs based on service regions. This extension allows a LoST 62 client to find the instances of the services and it's sub services, 63 by asking a LoST server for the list of sub services that it 64 supports. Even the deaf & dumb people or foreigner can make use of 65 the advantages of this draft to contact the sub service of the 66 instances of service, in which the LoST client is interested. 68 It provides an indication of which service and sub services the 69 server can look up. The sub services are the capabilities of the 70 given service. For example the sub service list of a PSAP can be 71 urn:service:sos.police.terrorist, urn:service:sos.police.arson, 72 urn:service:sos.police.robbery. This means that the given PSAP is 73 able to handle terrorist attack, robbery, and a wild fire. So the 74 clients come to know in advance whether a required sub service is 75 offered for a particular area. 77 This document describes how to get sub service list of the instance 78 of service, it can be accomplished by specifying additional 79 information in the query using the extension named, 'sub-service'. 80 Which will return all the sub services of requested service. 82 2. Terminology used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. LoST extension 90 A LoST client can ask a LoST server for the list of sub services it 91 knows about for a particular services in the given area. And he can 92 find the sub-service information from the . The 93 LoST client will be interested in any one of them or combination of 94 listed subservices. It will help a LoST client to locate the 95 instances of services, those match more closely to his interest. It 96 avoids the clients to query the service URIs returned to obtain 97 additional information about the services, thus reducing the number 98 of queries to be done to get the accurate search for the instances of 99 service. 101 In the current scenario, the client doesn't know what kind of 102 subservices the returned service uri supports, so he can't contact 103 the service uri with additional information(i.e. sub services or 104 service options the client wants) to get a better and timely service. 106 We Introduce a new attribute and element to achieve this task. 107 'getsubservice' for the element and 108 for the element. 110 4. sub-service 112 Suppose a LoST client is seeking help from the police to get 113 protection from a thief. Currently, the Location-to-Service 114 Translation (LoST) protocol only supports mapping of the locations of 115 police stations. There are no options to know any particular 116 information about the capabilities of the instance of the service. 117 Using the sub-service information, the LoST client can get the 118 details of a specific police station, which can handle a thief or 119 arson etc. 121 5. sub-service in Request 123 124 126 127 129 Germany 130 Bavaria 131 Munich 132 Otto-Hahn-Ring 133 6 134 81675 135 136 137 urn:service:sos.police 138 140 Figure 1: A query with 141 the new attribute. 143 Here the LoST client is searching for police stations in the given 144 area and finds it's capabilities. 146 6. sub-service in Response 148 149 150 155 156 Muenchen Polizei-Abteilung 157 158 urn:service:sos.police 159 160 urn:service:sos.police.terrorist 161 urn:service:sos.police.arson 162 urn:service:sos.police.robbery 163 164 166 168 Germany 169 Bavaria 170 Munich 171 81675 172 173 174 sip:munich-police@example.com 175 xmpp:munich-police@example.com 176 110 177 178 179 180 181 182 183 185 Figure 3: A civic address answer 186 with the new attribute. 188 The response of the previous query contains the details of the PSAP 189 in the specified service region and it's sub-service list. This 190 indicates that, the given instance of requested service is capable of 191 handling terrorist, theft and arson. And it tells a mobile device 192 what kind of sub services are available close by that location. The 193 LoST client can contact the service uri with additional information 194 (i.e. sub services or service options the client wants) so that he 195 will get a better and timely service from the requested uri. 197 7. Security Considerations 199 The same security considerations as in [LOST] apply. 201 8. IANA Considerations 203 TBD 205 9. References 207 9.1. Normative References 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, March 1997. 212 9.2. Informative References 214 [I-D.ietf-ecrit-lost] 215 Hardie, T., Newton, A., Schulzrinne, H., and H. 216 Tschofenig, "LoST: A Location-to-Service Translation 217 Protocol", draft-ietf-ecrit-lost-09 (work in progress), 218 March 2008. 220 [I-D.ietf-geopriv-pdif-lo-profile] 221 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 222 PIDF-LO Usage Clarification, Considerations and 223 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 224 (work in progress), February 2008. 226 Authors' Addresses 228 Robins George 229 Huawei Technologies 230 Huawei Base, Bantian, Longgang District 231 Shenzhen, Guangdong 518129 232 P. R. China 234 Phone: +86-755-28787584 235 Email: robinsg@huawei.com 237 Qian Sun 238 Huawei Technologies 239 Huawei Base, Bantian, Longgang District 240 Shenzhen, Guangdong 518129 241 P. R. China 243 Phone: +86-755-28787351 244 Email: sunqian@huawei.com 246 Full Copyright Statement 248 Copyright (C) The IETF Trust (2008). 250 This document is subject to the rights, licenses and restrictions 251 contained in BCP 78, and except as set forth therein, the authors 252 retain all their rights. 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 257 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 258 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 259 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Intellectual Property 264 The IETF takes no position regarding the validity or scope of any 265 Intellectual Property Rights or other rights that might be claimed to 266 pertain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; nor does it represent that it has 269 made any independent effort to identify any such rights. Information 270 on the procedures with respect to rights in RFC documents can be 271 found in BCP 78 and BCP 79. 273 Copies of IPR disclosures made to the IETF Secretariat and any 274 assurances of licenses to be made available, or the result of an 275 attempt made to obtain a general license or permission for the use of 276 such proprietary rights by implementers or users of this 277 specification can be obtained from the IETF on-line IPR repository at 278 http://www.ietf.org/ipr. 280 The IETF invites any interested party to bring to its attention any 281 copyrights, patents or patent applications, or other proprietary 282 rights that may cover technology that may be required to implement 283 this standard. Please address the information to the IETF at 284 ietf-ipr@ietf.org.