idnits 2.17.1 draft-forte-ecrit-service-urn-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 23, 2009) is 5513 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) No issues found here. 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. Forte 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia University 5 Expires: September 24, 2009 March 23, 2009 7 Policy for defining new service-identifying labels 8 draft-forte-ecrit-service-urn-policy-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 24, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 In order to provide location-based services, descriptive terms for 47 services need to be defined. This document updates the policy for 48 defining new service-identifying labels. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. New Service-Identifying Labels . . . . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 57 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1. Introduction 62 Nowadays location-based services are widespread. Devices can detect 63 a user location and retrieve all available services in the 64 sourroundings of that location. A particular service can be 65 described by one or multiple terms such as "restaurant", "parking" 66 and "ATM machine". All such terms, however, need to be formally 67 defined so that a registry can be built and used to assure 68 consistency and compatibility between devices and between service 69 providers. Since descriptive terms for services are almost 70 unbounded, such registry would contain the most common terms. In 71 this document we update the policy for defining new terms, that is 72 new service-identifying labels. 74 2. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 3. IANA Considerations 82 3.1. New Service-Identifying Labels 84 This document updates Section 4.1 of [RFC5031] in that the policy for 85 adding top-level service labels is "Expert Review". The expert is 86 designated by the RAI Area Director. 88 4. Security Considerations 90 This document does not raise security issues. 92 5. References 94 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 95 Requirement Levels", BCP 14, RFC 2119, March 1997. 97 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 98 Emergency and Other Well-Known Services", RFC 5031, 99 January 2008. 101 Authors' Addresses 103 Andrea G. Forte 104 Columbia University 105 Department of Computer Science 106 1214 Amsterdam Avenue, MC 0401 107 New York, NY 10027 108 USA 110 Email: andreaf@cs.columbia.edu 112 Henning Schulzrinne 113 Columbia University 114 Department of Computer Science 115 1214 Amsterdam Avenue, MC 0401 116 New York, NY 10027 117 USA 119 Email: hgs@cs.columbia.edu