idnits 2.17.1 draft-ietf-ecrit-service-urn-policy-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 date (May 2014) is 3627 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) ** Downref: Normative reference to an Informational RFC: RFC 6061 Summary: 2 errors (**), 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.G. Forte 3 Internet-Draft AT&T 4 Intended status: Best Current Practice H. Schulzrinne 5 Expires: October 31, 2014 Columbia University 6 May 2014 8 Policy for defining new service-identifying labels 9 draft-ietf-ecrit-service-urn-policy-04.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 October 31, 2014. 34 Copyright Notice 36 Copyright (c) 2014 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 (http://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 52 3. Namespace Guidelines . . . . . . . . . . . . . . . . . . . . . 2 53 4. Guidelines for the creation of new top-level services . . . . 2 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1. Introduction 61 Nowadays location-based services are widespread. Devices can detect 62 a user location and retrieve all available services in the 63 sourroundings of that location. A particular service can be 64 described by one or multiple terms such as "restaurant", "parking" 65 and "ATM machine". All such terms, however, need to be formally 66 defined so that a registry can be built and used to assure 67 consistency and compatibility between devices and between service 68 providers. Since descriptive terms for services are almost 69 unbounded, such registry would contain the most common terms. In 70 this document we update the policy for defining new terms, that is 71 new service-identifying labels. 73 2. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 3. Namespace Guidelines 81 [NOTE: Have we agreed on this approach that is, do we allow private 82 namespaces?] 84 Whereas one entity applies for the registraton of several new top- 85 level services which are of no interest to the general public, the 86 expert reviewer SHOULD consider the creation of an ad-hoc private 87 namespace (e.g., urn:nena [RFC6061]) under which such entity would be 88 free to define its own set of services and service labels. 90 On the other hand, if the new top-level services are of interest to 91 the general public or there is just one single top-level service to 92 be registered, the expert reviewer SHOULD decide for registration in 93 the public namespace domain (i.e., urn:service). 95 Namespaces MAY, at their discretion, use discovery mechanisms other 96 than the one described in [RFC5222]. 98 4. Guidelines for the creation of new top-level services 100 [NOTE: Should this section apply only to the public namespace domain? 101 Do we want to give some general guidelines for private namespaces as 102 well?] 104 The number of services that can be defined is very large. New 105 services, however, SHOULD at least satisfy the following guidelines. 107 - The service MUST NOT overlap with any other service previously 108 registered; 109 - The service has to be of general interest; 111 - It should not be specific to a particular country or region; 113 - The language in which the new service is defined MUST be English 114 (this is a protocol token, not meant to be shown to humans); 116 - The newly defined services SHOULD correspond to a standard 117 statistical classification of enterprises or services, such as the 118 North American Industry Classification System (NAICS) and the 119 International Standard Industrial Classification of All Economic 120 Activities (ISIC). 122 5. IANA Considerations 124 This document updates Section 4.1 of [RFC5031] in that the policy for 125 adding top-level service labels is "Expert Review". The expert is 126 designated by the RAI Area Director. 128 [NOTE: Add requirement for external non-IETF document or template 129 here?] 131 6. Security Considerations 133 This document does not raise security issues. 135 7. References 137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 138 Requirement Levels", BCP 14, RFC 2119, March 1997. 140 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 141 Emergency and Other Well-Known Services", RFC 5031, 142 January 2008. 144 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, 145 "LoST: A Location-to-Service Translation Protocol", RFC 146 5222, August 2008. 148 [RFC6061] Rosen, B., "Uniform Resource Name (URN) Namespace for the 149 National Emergency Number Association (NENA)", RFC 6061, 150 January 2011. 152 Authors' Addresses 154 Andrea G. Forte 155 AT&T 156 Security Research Center 157 33 Thomas Street 158 New York, NY 10007 159 USA 161 Email: forte@att.com 162 Henning Schulzrinne 163 Columbia University 164 Department of Computer Science 165 1214 Amsterdam Avenue, MC 0401 166 New York, NY 10027 167 USA 169 Email: hgs@cs.columbia.edu