idnits 2.17.1 draft-ietf-ecrit-service-urn-policy-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (June 11, 2012) is 4337 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Forte 3 Internet-Draft AT&T 4 Intended status: BCP H. Schulzrinne 5 Expires: December 13, 2012 Columbia University 6 June 11, 2012 8 Policy for defining new service-identifying lables 9 draft-ietf-ecrit-service-urn-policy-00.txt 11 Abstract 13 In order to provide location-based services, descriptive terms for 14 services need to be defined. This document updates the policy for 15 defining new service-identifying labels. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 13, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 55 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1. Introduction 60 Nowadays location-based services are widespread. Devices can detect 61 a user location and retrieve all available services in the 62 sourroundings of that location. A particular service can be 63 described by one or multiple terms such as "restaurant", "parking" 64 and "ATM machine". All such terms, however, need to be formally 65 defined so that a registry can be built and used to assure 66 consistency and compatibility between devices and between service 67 providers. Since descriptive terms for services are almost 68 unbounded, such registry would contain the most common terms. In 69 this document we update the policy for defining new terms, that is 70 new service-identifying labels. 72 2. Requirements notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 3. IANA Considerations 80 This document updates Section 4.1 of [RFC5031] in that the policy for 81 adding top-level service labels is "Expert Review". The expert is 82 designated by the RAI Area Director. 84 4. Security Considerations 86 This document does not raise security issues. 88 5. References 90 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 91 Requirement Levels", BCP 14, RFC 2119, March 1997. 93 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 94 Emergency and Other Well-Known Services", RFC 5031, 95 January 2008. 97 Authors' Addresses 99 Andrea G. Forte 100 AT&T 101 Security Research Center 102 33 Thomas Street 103 New York, NY 10007 104 USA 106 Email: forte@att.com 108 Henning Schulzrinne 109 Columbia University 110 Department of Computer Science 111 1214 Amsterdam Avenue, MC 0401 112 New York, NY 10027 113 USA 115 Email: hgs@cs.columbia.edu