idnits 2.17.1 draft-earnshaw-tv-anytime-crid-04.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.a on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 443. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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 == Line 349 has weird spacing: '...ersonal stora...' == Line 361 has weird spacing: '...ersonal stora...' -- 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 (November 22, 2004) is 7095 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: 'RFC2717' is defined on line 374, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TVA-Sys' -- Possible downref: Non-RFC (?) normative reference: ref. 'TVA-CR' -- Possible downref: Non-RFC (?) normative reference: ref. 'TVA-Met' -- Possible downref: Non-RFC (?) normative reference: ref. 'TVA-Prt' ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group N. Earnshaw 2 Internet-Draft BBC Research and Development 3 Expires: May 23, 2005 S. Aoki 4 TokyoFM Broadcasting 5 A. Ashley 6 NDS Limited 7 W. Kameyama 8 GITS, Waseda University 9 November 22, 2004 11 The TV-Anytime Content Reference Identifier (CRID) 12 draft-earnshaw-tv-anytime-crid-04.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. This document may not be modified, and derivative works of 22 it may not be created, except to publish it as an RFC and to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 23, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2004). 47 Abstract 48 The Uniform Resource Locator (URL) scheme "CRID:" has been devised to 49 allow references to current or future scheduled publications of 50 broadcast media content over television distribution platforms and 51 the Internet. 53 The initial intended application is as an embedded link within 54 scheduled programme description metadata that can be used by the home 55 user or agent to associate a programme selection with the 56 corresponding programme location information for subsequent automatic 57 acquisition. 59 This document reproduces the TV-Anytime CRID definition found in the 60 TV-Anytime content referencing specification, and is published as an 61 RFC for ease of access and registration with the Internet Assigned 62 Numbers Authority (IANA). 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Ancestry . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Notation used in this document . . . . . . . . . . . . . . . . 5 69 4. The CRID URL Scheme . . . . . . . . . . . . . . . . . . . . . 5 70 5. Examples of CRID syntax . . . . . . . . . . . . . . . . . . . 5 71 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6.1 Normative Specification . . . . . . . . . . . . . . . . . 6 73 6.2 Role of Domain Name System (DNS) namespace . . . . . . . . 6 74 6.3 CRID resolving . . . . . . . . . . . . . . . . . . . . . . 6 75 6.4 CRID Related Metadata . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.2 Registration Template in accordance with RFC2717 . . . . . 7 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 82 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 Intellectual Property and Copyright Statements . . . . . . . . 12 85 1. Introduction 87 In recent years there has been an expansion in the number of 88 broadcast television and radio services available to the home. In 89 addition to the broadcast services delivered over traditional 90 distribution channels such as Digital Terrestrial, Satellite and 91 Cable, the advent of high speed internet connection to the home will 92 give rise to new information and entertainment services providing 93 audio visual programme material sourced directly to the home over the 94 Internet. 96 Alongside this expansion there is also an increased growth in 97 complexity of the device available to the home user that will allow 98 the home user to operate in a 'search-select-acquire' paradigm. In 99 this model the user or user agent uses descriptive information about 100 audio visual programmes as a basis for selecting the programme for 101 subsequent acquisition and viewing. Increasingly home appliances are 102 being furnished with local storage enabling the automatic capture of 103 the programme material through off air recording or downloading by 104 the home appliance. 106 The 'CRID:' Uniform Resource Locator is designed to be the bridge 107 between programme related descriptive metadata and corresponding 108 programme location data that may be published over a different 109 distribution network or at a different time. 111 Programme location data provides the home user agent with the 112 information required to acquire the programme at the time of 113 publication. In the case of the television distribution model these 114 locators provide programme broadcast timing and tuning information 115 such that the user appliance can record the programme when broadcast 116 in real time. For the case of internet delivery the locators need to 117 be of the form associated with streaming protocols or file exchange 118 protocols with the time (or time window) of availability indicated. 120 Since a content publisher may release audio video material in the 121 same form on a number of platforms, or repeatedly over some time 122 interval, the CRID can be used to aggregate these different 123 publications and associate them with a single description. 124 Furthermore, there may be other meaningful semantic associations 125 between otherwise unrelated programme publications with assigned CRID 126 that can be further aggregated under a higher level CRID. This 127 higher level CRID can be described through its own descriptive 128 metadata. The subjective nature of such aggregation decisions is 129 part of the CRID authoring process and is not standardised. 131 The CRID resolution process ultimately enabling the user agent to 132 acquire the audio visual programme material may be a timely process, 133 with resolution updates delivered dynamically from the service 134 provider. This is to reflect common business practice of adjusting 135 the time of content availability close to the original published time 136 to accommodate a live, managed, reactive broadcast service. 138 2. Ancestry 140 The Uniform Resource Locator scheme 'CRID:' is taken from the 141 TV-Anytime forum Content Reference Identifier and is a result of the 142 consensus reached by members of this forum between March 2000 and 143 June 2002. The TV-Anytime CRID and associated supporting data is 144 specified in the TV-Anytime Phase 1 Content Referencing Specification 145 [TVA-CR]. 147 3. Notation used in this document 149 The notation used in this document takes the form 151 / 153 in which the component names are in angle brackets and any characters 154 outside angle brackets are literal separators. 156 4. The CRID URL Scheme 158 The CRID URL takes the form 160 crid:/// 162 where is a registered internet domain name which takes the 163 form of domain name described in Section 3 of [RFC1034] and Section 164 2.1 of [RFC1123]. 166 is a free format string that is URI [RFC2396] compliant, and 167 is meaningful to the authority given by the authority field. The 168 portion of the field is case insensitive. It is recommended that all 169 characters not within the range of characters allowed in a URI must 170 be encoded into UTF-8 and included in the URI as a sequence of 171 escaped octets. An escaped octet is encoded as a character triplet, 172 consisting of the percent character "%" followed by the two 173 hexadecimal digits representing the octet code. 175 In its entirety, the CRID is URI compliant as specified in [RFC2396]. 176 As per [RFC2396] the crid:// part of the syntax is case insensitive. 178 5. Examples of CRID syntax 180 Examples of valid CRID. 182 crid://example.com/foobar 184 CRID created by "example.com" authority, with data part of foobar. 186 crid://example.co.jp/%E3%82%A8%E3%82%A4%E3%82%AC 188 CRID created by "example.co.jp" authority, with a data part of "E", 189 "I" and "GA" (meaning "movie"), represented as KATAKANA LETTERS 190 (Japanese characters) in UTF-8 encoding preceded by "%". 192 6. Usage 194 6.1 Normative Specification 196 The Uniform Resource Locator scheme 'CRID:' identifies the URL as the 197 TV-Anytime Content Reference Identifier and conforms to the 198 TV-Anytime Content Referencing Specification [TVA-CR]. The 199 TV-Anytime CRID is a key component in the TV-Anytime forum 200 specification series as described in the informative overview Systems 201 Description Specification [TVA-Sys]. The normative Content 202 Referencing Specification [TVA-CR] also includes the details of the 203 contents and format of the associated content referencing tables that 204 resolve the TV-Anytime CRID into further CRID instances or transport 205 system dependent locations. 207 6.2 Role of Domain Name System (DNS) namespace 209 It is important to note that the use of the registered Internet 210 Domain does not mean the DNS resolving service is to be employed for 211 the resolution of CRID URL. Indeed the resolution information is 212 fully specified in [TVA-CR] and does not require the use of the DNS 213 resolution service. This is especially important as one key 214 application area is broadcast television and radio distribution 215 services that are not internet based. 217 For the case of business scenarios that do exploit Internet 218 connectivity to the home, the DNS portion of the CRID can be used to 219 resolve the internet location of the service provider who in turn 220 will provide location resolution information in a form described in 221 [TVA-CR]. 223 6.3 CRID resolving 225 As addressed in [TVA-CR] the CRID is ultimately resolved either 226 directly by the CRID authority or by another party. If another party 227 is providing resolution, the ability to resolve the CRID requires the 228 flow of some information from the authority to the resolution 229 provider, in order to tie the CRID to its resolution. Examples of 230 relationships between CRID authors and the suppliers of resolution 231 information are given in [TVA-Sys]. 233 As described in [TVA-CR] there will in all likelihood be more than 234 one CRID that can resolve directly or indirectly to a given single 235 locator at a given time. 237 Also shown in [TVA-CR] CRIDs that resolve directly to the location of 238 the scheduled content are likely to resolve to more than one location 239 as television and radio programmes are often published repeatedly 240 within broadcast schedules or across different broadcast services or 241 distribution platforms over an extended period of time. 243 6.4 CRID Related Metadata 245 TV-Anytime specification [TVA-Met] specifies the format and contents 246 of the programme related descriptive metadata designed to convey the 247 TV-Anytime CRID for the purpose outlined here as well as other data 248 supporting the publication and usage of programme material. 250 7. IANA Considerations 252 7.1 General 254 The 'crid:' URI scheme should be reserved to designate that the URI 255 relates to the TV-Anytime CRID and is to be used in accordance with 256 the TV-Anytime Content Referencing Specification [TVA-CR]. 258 The designation of the value of each CRID is the responsibility of 259 the CRID author, as identified through the 'authority' field. 261 The policy of assignment of CRID values lies with the CRID author 262 associated with the authority field. It is likely that there will be 263 a number of diverse (and possibly changing) authoring policies as 264 required by various organisations as they address their respective 265 audiences. These individual policies will address such resolution 266 target resource designation issues as: the subjective equivalence of 267 programme material available from different locations, the grouping 268 of CRIDs under another CRID for collective description and resolution 269 purposes, the cross referencing of CRID between authorities, CRID 270 lifetime and CRID reuse. 272 It is likely that some authoring policies may be set through 273 collaborative business arrangements, localised operational agreements 274 or through national governmental bodies. 276 7.2 Registration Template in accordance with RFC2717 277 URL scheme name: crid 279 URL scheme syntax: See Section 4 281 Character encoding considerations: TV-Anytime does not specify the 282 character encoding scheme to be adopted by each implementation. 283 However, in the case where internet interoperability is desired, it 284 is recommended that all characters not within the range of characters 285 allowed in a URI must be encoded into UTF-8 and included in the URI 286 as a sequence of escaped octets. An escaped octet is encoded as a 287 character triplet, consisting of the percent character "%" followed 288 by the two hexadecimal digits representing the octet code. For 289 example, the character A would be represented as "A", the character 290 LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80", 291 and the character KATAKANA LETTER A would be represented as 292 "%E3%82%A2". 294 Intended Use: See Section 6 296 Application and protocols which use this scheme: See Section 6 298 Interoperability considerations: None (Section 4 contains the first 299 version of the CRID URL definition) 301 Security considerations: See Section 8 303 Relevant publications: See [TVA-CR], [TVA-Met], [TVA-Sys], [TVA-Prt] 305 Contact: Wataru KAMEYAMA, Vice Chairman and Secretary of the 306 TV-Anytime Forum, wataru@waseda.jp 308 Author/Change controller: IESG 310 8. Security Considerations 312 The CRID URL described here provides a referencing mechanism. The 313 values of the URL contain the authoring 'Authority' name as a DNS 314 namespace identifier and a data portion to distinguish it from other 315 CRIDs from the same authority. There should be no reason to prevent 316 disclosure of the values within the CRID and no commercial 317 sensitivity associated with these values. 319 When conveyed as part of a larger data set which may have commercial 320 value or critical binding between a CRID and the accompanying data, 321 then the security and integrity of the binding is a matter for the 322 wider system implementers to judge and protect accordingly. One such 323 method for protecting metadata can be found in [TVA-Prt], though it 324 is not mandated that users adopt this. In any case there may be 325 other wider system security functions in place or the absence of 326 perceived need for such precautions. 328 Tampering with values of CRIDs during transmission or distribution 329 over public or open networks has only nuisance or denial of service 330 effects unless it causes alternative location resolution data or 331 programme metadata to be referenced. Again this can be dealt with as 332 a system delivery of data integrity issue not specific to the CRID. 334 Impersonating a CRID authority by authoring CRID with an authority 335 portion for which the bogus author does not have permission from the 336 registered DNS name holder would be a misuse of the DNS name holder's 337 identity and should be dealt with through normal business practice. 339 9 References 341 [TVA-Sys] European Telecommunications Standards Institute, "ETSI TS 342 102 822-2 v1.2.1 ; Broadcast and On-line Services: Search, 343 select and rightful use of content on personal storage 344 systems ("TV-Anytime Phase 1"). Part 2 System 345 Description", September 2004. 347 [TVA-CR] European Telecommunications Standards Institute, "ETSI TS 348 102 822-4 v1.1.2 ; Broadcast and On-line Services: Search, 349 select and rightful use of content on personal storage 350 systems ("TV-Anytime Phase 1"); Part 4: Content 351 referencing", October 2004. 353 [TVA-Met] European Telecommunications Standards Institute, "ETSI TS 354 102 822-3-1 v1.2.1 ; Broadcast and On-line Services: 355 Search, select and rightful use of content on personal 356 storage systems ("TV-Anytime Phase 1"). Part 3 Metadata. 357 Sub-part 1: Metadata Schemas", September 2004. 359 [TVA-Prt] European Telecommunications Standards Institute, "ETSI TS 360 102 822-7 v1.1.1 ; Broadcast and On-line Services: Search, 361 select and rightful use of content on personal storage 362 systems ("TV-Anytime Phase 1"). Part 7 Bi-directional 363 Metadata Delivery Protection", October 2003. 365 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 366 November 1987. 368 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 369 and Support", October 1989. 371 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 372 Resource Identifiers (URI): Generic Syntax", August 1998. 374 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL 375 Scheme Names", November 1999. 377 Authors' Addresses 379 Nigel Earnshaw 380 BBC Research and Development 381 Kingswood Warren 382 Tadworth, Surrey KT20 6NP 383 United Kingdom 385 Phone: +44 1737 839618 386 EMail: nigel.earnshaw@rd.bbc.co.uk 388 Shigeru Aoki 389 TokyoFM Broadcasting 390 1-7 Kojimachi 391 Chiyoda-ku, TOKYO 102-8080 392 JAPAN 394 Phone: +81 3 3221 0244 395 EMail: shig@center.jfn.co.jp 397 Alex Ashley 398 NDS Limited 399 One London Road 400 Staines, Middlesex TW18 4EX 401 United Kingdom 403 Phone: +44 208 4768270 404 EMail: aashley@ndsuk.com 406 Wataru Kameyama 407 GITS, Waseda University 408 1011 Okuboyama, Nishi-tomida 409 Honjo-shi, SAITAMA 367-0035 410 JAPAN 412 Phone: +81 495 24 6052 413 EMail: wataru@waseda.jp 415 Appendix A. Acknowledgements 417 The authors would like to acknowledge the support of the members of 418 the TV-Anytime forum and their work in the development of the 419 TV-Anytime CRID. 421 Intellectual Property Statement 423 The IETF takes no position regarding the validity or scope of any 424 Intellectual Property Rights or other rights that might be claimed to 425 pertain to the implementation or use of the technology described in 426 this document or the extent to which any license under such rights 427 might or might not be available; nor does it represent that it has 428 made any independent effort to identify any such rights. Information 429 on the procedures with respect to rights in RFC documents can be 430 found in BCP 78 and BCP 79. 432 Copies of IPR disclosures made to the IETF Secretariat and any 433 assurances of licenses to be made available, or the result of an 434 attempt made to obtain a general license or permission for the use of 435 such proprietary rights by implementers or users of this 436 specification can be obtained from the IETF on-line IPR repository at 437 http://www.ietf.org/ipr. 439 The IETF invites any interested party to bring to its attention any 440 copyrights, patents or patent applications, or other proprietary 441 rights that may cover technology that may be required to implement 442 this standard. Please address the information to the IETF at 443 ietf-ipr@ietf.org. 445 Disclaimer of Validity 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 450 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 451 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 452 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Copyright Statement 457 Copyright (C) The Internet Society (2004). This document is subject 458 to the rights, licenses and restrictions contained in BCP 78, and 459 except as set forth therein, the authors retain all their rights. 461 Acknowledgment 463 Funding for the RFC Editor function is currently provided by the 464 Internet Society. 466