idnits 2.17.1 draft-gonze-media-type-xspf-01.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 196. ** 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. 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 an Introduction section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 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 (September 23, 2006) is 6424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Gonze 3 Internet-Draft Yahoo! Music 4 Intended status: Informational September 23, 2006 5 Expires: March 27, 2007 7 The application/xspf+xml Media Type 8 draft-gonze-media-type-xspf-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 27, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines a new media type for the XML Shareable Playlist 42 Format (XSPF, pronounced like "spiff"). XSPF allows playlists to be 43 exchanged between different software, across networks and across 44 administrative boundaries. A media type registration enhances 45 shareability. 47 An XSPF playlist describes a sequence of objects to be rendered in 48 time. Objects might be audio, video, text, playlists, or any other 49 media type with an inherent duration. The function of an XSPF 50 document is to identify the objects and communicate their order. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 55 2. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Security considerations . . . . . . . . . . . . . . . . . . . . 6 57 4. Normative References . . . . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . . . 9 61 1. Requirements notation 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 2. Registration 69 Type name: application 71 Subtype name: xspf+xml 73 Required parameters: none 75 Optional parameters: charset. Same as charset parameter of 76 application/xml as specified in [RFC3023]. 78 Encoding considerations: Same as encoding considerations of 79 application/xml as specified in [RFC3023]. 81 Interoperability considerations: Versions 0 and 1 are compatible 82 except for some playlist publication dates which precede the first 83 publication of either specification, hence are impossible in 84 practice. This media type registration encompasses both versions. 86 Published specification: 88 http://xspf.org/xspf-v1 (version 1) 90 http://xspf.org/xspf-v0 (version 0) 92 Applications that use this media type: Gnomoradio, Webjay.org, 93 Musicplayer, Playr, Jinzora, Yahoo Music Engine, Serpentine, 94 Plurn, ultraPh0nZ FMP256, Spiffy, Plext, BMPx, I/ON, Drupal 95 playlist module, Wordpress playlist module, Ning, Music For 96 Dozens, Musicmobs/Mobster, VLC media player, AmaroK, Pear:: 97 Package::File_XSPF, CPAN XML::XSPF, Odeo, Jamendo, ArtistServer, 98 Project Opus, (others) 100 Additional information: 102 Magic number(s): none, but see section 3.1 of [RFC3023]. 104 File extension(s): .xspf 106 Macintosh file type code(s): "TEXT" 108 Fragment/anchor identifiers: see [RFC3023]. 110 Person & email address to contact for further information: Lucas 111 Gonze 113 Intended usage: COMMON 115 Restrictions on usage: none 117 Author/change controller: The XSPF specification is a work product 118 of the Xiph.org Foundation's Playlist Ad Hoc Group. The working 119 group's home on the web is http://xspf.org. The specifications 120 were edited by Lucas Gonze , Matthias Friedrich 121 , and Robert Kaye . 123 XML namespace: http://xspf.org/ns/0 125 Base URIs: see [RFC3023]. 127 BOM: see [RFC3023]. 129 3. Security considerations 131 The XML-based media type being registered has all of the security 132 considerations described in [RFC3023] plus additional 133 considerations. 135 Playlist authors who publish documents containing local filesystem 136 paths should take care to not reveal confidential information 137 contained in those strings. 139 The registration does not employ active content. 141 4. Normative References 143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 144 Requirement Levels", BCP 14, RFC 2119, March 1997. 146 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 147 Types", RFC 3023, January 2001. 149 Author's Address 151 Lucas Gonze 152 Yahoo! Music 153 Venice, CA 154 US 156 Email: lucas@gonze.com 158 Full Copyright Statement 160 Copyright (C) The Internet Society (2006). 162 This document is subject to the rights, licenses and restrictions 163 contained in BCP 78, and except as set forth therein, the authors 164 retain all their rights. 166 This document and the information contained herein are provided on an 167 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 168 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 169 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 170 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 171 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 172 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 174 Intellectual Property 176 The IETF takes no position regarding the validity or scope of any 177 Intellectual Property Rights or other rights that might be claimed to 178 pertain to the implementation or use of the technology described in 179 this document or the extent to which any license under such rights 180 might or might not be available; nor does it represent that it has 181 made any independent effort to identify any such rights. Information 182 on the procedures with respect to rights in RFC documents can be 183 found in BCP 78 and BCP 79. 185 Copies of IPR disclosures made to the IETF Secretariat and any 186 assurances of licenses to be made available, or the result of an 187 attempt made to obtain a general license or permission for the use of 188 such proprietary rights by implementers or users of this 189 specification can be obtained from the IETF on-line IPR repository at 190 http://www.ietf.org/ipr. 192 The IETF invites any interested party to bring to its attention any 193 copyrights, patents or patent applications, or other proprietary 194 rights that may cover technology that may be required to implement 195 this standard. Please address the information to the IETF at 196 ietf-ipr@ietf.org. 198 Acknowledgment 200 Funding for the RFC Editor function is provided by the IETF 201 Administrative Support Activity (IASA).