idnits 2.17.1 draft-kameyama-tv-anytime-urn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 17, 2003) is 7582 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) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kameyama 3 Internet-Draft GITS, Waseda University 4 Expires: January 16, 2004 July 17, 2003 6 A URN Namespace for the TV-Anytime Forum 7 draft-kameyama-tv-anytime-urn-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft expires on January 16, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes a Uniform Resource Name (URN) namespace that 39 is engineered by the TV-Anytime Forum for naming persistent resources 40 published by the TV-Anytime Forum including the TV-Anytime Forum 41 Standards, XML (Extensible Markup Language) Document Type 42 Definitions, XML Schemas, Namespaces, and other documents. 44 1. Introduction 46 The TV-Anytime Forum produces many kinds of documents: 48 specifications, working documents, schemas, etc. that currently being 49 considered for adoption by many standardization bodies such as ETSI 50 (European Telecommunication Standardization Institute), DVB (Digital 51 Video Broadcasting), ARIB (Association of Radio Industries and 52 Businesses) and ATSC (Advance Television Systems Committee). 54 The TV-Anytime Forum wishes to provide global, distributed, 55 persistent, location-independent names for these resources. 57 2. Specification Template 59 Namespace ID: 61 "tva" requested. 63 Registration information: 65 Registration Version Number: 1 66 Registration Date: 2003-07-17 68 Declared registrant of the namespace: 70 Name: Wataru KAMEYAMA 71 Title: Vice Chairman and Secretary, The TV-Anytime Forum 72 Affiliation: Graduate School of Global Information 73 and Telecommunication Studies, Waseda University 74 Address: 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 75 169-0051, JAPAN 76 Phone: +81 3 5286 9852 77 Email: wataru@waseda.jp 79 Declaration of structure: 81 The Namespace Specific String (NSS) of all URNs assigned by the 82 TV-Anytime Forum will have the following hierarchical structure: 84 urn:tva:{category}:{string} 86 where the "category" is a US-ASCII string that conforms to URN 87 syntax requirements ([RFC2141]), and "{string}" is a string that 88 confirms to URN syntax requirements ([RFC2141]). 90 Relevant ancillary documentation: 92 The TV-Anytime Forum specifications have been publicly available 93 at all stages during their development from 94 "ftp://tva:tva@ftp.bbc.co.uk/Specifications/". The final 95 specifications are now available as formal ETSI (European 96 Telecommunication Standardization Institute) technical 97 specification document, ETSI TS 102 822. 99 Identifier uniqueness considerations: 101 The TV-Anytime Forum shall establish unique identifiers as 102 appropriate. 104 Uniqueness is guaranteed as long as the assigned "{category}" is 105 never reassigned for another categories. The TV-Anytime Forum is 106 responsible for this. 108 Identifier persistence considerations: 110 The TV-Anytime Forum is committed to maintaining the accessibility 111 and persistence of all resources that are officially assigned URNs 112 by the organization. Persistence of identifiers is dependent upon 113 suitable delegation at the level of "category"s, and persistence 114 of category assignment. 116 Process of identifier assignment: 118 All the assignments of identifiers are fully controlled and 119 managed by the TV-Anytime Forum. 121 Process of identifier resolution: 123 The namespace is not listed with an RDS; this is not relevant. 125 Rules for Lexical Equivalence: 127 The "{category}" is case-insensitive. Thus, the portion of the 128 URN: 130 urn:tva:{category}: 132 is case-insensitive for matches. The remainder of the identifier 133 shall be considered case-sensitive, and so URNs are only lexically 134 equivalent if they are also lexically identical in the remaining 135 {string} field. 137 Conformance with URN Syntax: 139 No special considerations. 141 Validation mechanism: 143 Validation shall be done by a syntax grammar corresponding to each 144 "{category}". 146 Scope: 148 Global. 150 3. Examples 152 The following examples are not guaranteed to be real. They are 153 provided for pedagogical reasons only. 155 urn:tva:metadata:2002 156 urn:tva:metadata:cs:IntentionCS:2002 157 urn:tva:metadata:cs:ActionTypeCS:2002 158 urn:tva:rmp:tvax 160 4. Security Considerations 162 There are no additional security considerations other than those 163 normally associated with the use and resolution of URNs in general. 165 References 167 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997 169 Author Address 171 Wataru KAMEYAMA 172 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo, 169-0051, JAPAN 173 Phone: +81 3 5286 9852 174 Email: wataru@waseda.jp