idnits 2.17.00 (12 Aug 2021) /tmp/idnits56048/draft-sun-ecrit-unsafe-areas-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 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 294. 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) == Unused Reference: 'I-D.ietf-ecrit-lost' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-pdif-lo-profile' is defined on line 226, 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 (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Q. Sun 3 Internet-Draft R. George 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 2, 2009 July 1, 2008 7 Specifying Unsafe Areas in LoST Service Boundary 8 draft-sun-ecrit-unsafe-areas-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 to specify unsafe areas in LoST for 38 emergency services, such as police, mountain, marine and fire. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. Terminology used in this document . . . . . . . . . . . . . . . 3 44 3. LoST extensions . . . . . . . . . . . . . . . . . . . . . . . . 3 45 3.1. Request unsafe areas . . . . . . . . . . . . . . . . . . . 4 46 3.2. Specifying unsafe areas in the response . . . . . . . . . . 4 47 3.3. Additional information about the . . . . . . . 6 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 49 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 50 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 52 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 54 Intellectual Property and Copyright Statements . . . . . . . . . . 8 56 1. Introduction 58 The Location-to-Service Translation Protocol (LoST) describes a 59 protocol for mapping service identifiers and location information to 60 URLs of the service instance. The region of a service instance can 61 also be provided in one or more serviceBoundary elements. 63 According to the research of patterns of crime, the spatial 64 differentiation of crimes occurred in the city is obvious. There are 65 a few pretty dangerous areas with high crime rate in many big cities, 66 which may be identified and published by police departments. For 67 example monthly crime hot spots identified by phoenix police 68 department [Monthly_Violent]. 70 This document helps to find out unsafe areas in the service region. 71 These unsafe areas are the one where frequent crime (e.g. theft, 72 robbery, pickpockets), accidents or some other incidents are 73 happening. There may be more than one unsafe area in a service 74 region, and of course, may be zero. 76 When the user enters in to an unsafe area where frequent pickpockets 77 are happening, the user's device will prompt him the warning "many 78 pick-pockets are in this area, especially at bus stops" and the 79 seriousness of the problem. So that he can take necessary 80 precautions to handle the given situation after entering in this 81 area. To achieve this task, we add new elements named unsafeArea, 82 note, and rank in the . the unsafe area is 83 requested by the client, using the 'unsafeArea' attribute in the 84 request with the value set to "value" or "reference". 86 The LoST client's device can prompt a user when he enters in to an 87 area which has or might have a natural disaster threats like flood, 88 snowslide, landslip, wild fire etc, or when he drives in to an 89 accident prone area. Sailing or swimming people can also find out 90 the dangerous areas with submerged rocks or sharks. 92 2. Terminology used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. LoST extensions 100 The LoST client can ask the server to return unsafe areas. And we 101 introduce a new attribute in LoST request named 102 'unsafeArea' for this purpose. 104 We introduce new elements in LoST response 105 named, , and to describe the unsafe areas 106 and its information. 108 3.1. Request unsafe areas 110 The new attribute 'unsafeArea' in LoST request 111 indicates the LoST client wants to get the unsafe areas information 112 of the determined service instance. 114 115 122 123 124 37.775 -122.422 125 126 127 urn:service:sos.police 129 131 Figure 1: A query 133 3.2. Specifying unsafe areas in the response 135 The new element is used to specify the dangerous areas 136 in the service region. A element contains at least one 137 element. An area boundary circumscribes the unsafe 138 region. It has the similar semantics with serviceBoundary element. 140 And he gets the response with the details: 142 143 145 151 152 New York City Police Department 153 154 urn:service:sos.police 155 156 157 158 159 37.775 -122.4194 160 37.555 -122.4194 161 37.555 -122.4264 162 37.775 -122.4264 163 37.775 -122.4194 164 165 166 167 168 sip:nypd@example.com 169 xmpp:nypd@example.com 170 911 171 172 173 174 37.565 -122.4224 175 176 250.12 177 178 179 180 5 181 robbery often happens in the night 182 183 184 185 186 187 188 189 191 Figure 2: A 193 3.3. Additional information about the 195 The new element can be used to specify the additional 196 information about the unsafe area. It could be some suggestion or 197 warning text about this area. This message in the response 198 may be prompted when the LoST client enters in to the given unsafe 199 area, together with the seriousness, i.e. the element. The 200 value of the element is a number from 1 to 5, 5 means the most 201 serious situation. 203 4. Security Considerations 205 TBD 207 5. IANA Considerations 209 TBD 211 6. References 213 6.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 6.2. Informative References 220 [I-D.ietf-ecrit-lost] 221 Hardie, T., Newton, A., Schulzrinne, H., and H. 222 Tschofenig, "LoST: A Location-to-Service Translation 223 Protocol", draft-ietf-ecrit-lost-09 (work in progress), 224 March 2008. 226 [I-D.ietf-geopriv-pdif-lo-profile] 227 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 228 PIDF-LO Usage Clarification, Considerations and 229 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 230 (work in progress), February 2008. 232 [Monthly_Violent] 233 Police Headquarters, Phoenix, 234 "http://phoenix.gov/POLICE/ucr_monthly_violent.pdf". 236 Authors' Addresses 238 Qian Sun 239 Huawei Technologies 240 Huawei Base, Bantian, Longgang District 241 Shenzhen, Guangdong 518129 242 P. R. China 244 Phone: +86-755-28787351 245 Email: sunqian@huawei.com 247 Robins George 248 Huawei Technologies 249 Huawei Base, Bantian, Longgang District 250 Shenzhen, Guangdong 518129 251 P. R. China 253 Phone: +86-755-28789961 254 Email: robinsg@huawei.com 256 Full Copyright Statement 258 Copyright (C) The IETF Trust (2008). 260 This document is subject to the rights, licenses and restrictions 261 contained in BCP 78, and except as set forth therein, the authors 262 retain all their rights. 264 This document and the information contained herein are provided on an 265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 267 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 268 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 269 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 272 Intellectual Property 274 The IETF takes no position regarding the validity or scope of any 275 Intellectual Property Rights or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; nor does it represent that it has 279 made any independent effort to identify any such rights. Information 280 on the procedures with respect to rights in RFC documents can be 281 found in BCP 78 and BCP 79. 283 Copies of IPR disclosures made to the IETF Secretariat and any 284 assurances of licenses to be made available, or the result of an 285 attempt made to obtain a general license or permission for the use of 286 such proprietary rights by implementers or users of this 287 specification can be obtained from the IETF on-line IPR repository at 288 http://www.ietf.org/ipr. 290 The IETF invites any interested party to bring to its attention any 291 copyrights, patents or patent applications, or other proprietary 292 rights that may cover technology that may be required to implement 293 this standard. Please address the information to the IETF at 294 ietf-ipr@ietf.org.