idnits 2.17.1 draft-snell-atompub-link-extensions-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 518. ** 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 '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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2005) is 6730 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) == Missing Reference: 'TM' is mentioned on line 475, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft November 2005 4 Expires: May 5, 2006 6 Atom Syndication Format Link Extensions 7 draft-snell-atompub-link-extensions-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 5, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This specification defines extensions to the Atom Syndication Format 41 link and content elements that may be used to express additional 42 metadata about linked resources. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 48 3. Entity Attributes . . . . . . . . . . . . . . . . . . . . . . 3 49 3.1. The 'md5' Attribute . . . . . . . . . . . . . . . . . . . 3 50 3.2. The 'etag' Attribute . . . . . . . . . . . . . . . . . . . 4 51 3.3. The 'last-modified' Attribute . . . . . . . . . . . . . . 4 52 3.4. The 'range' Attribute . . . . . . . . . . . . . . . . . . 5 53 4. Media Descriptors . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. The 'media' Attribute . . . . . . . . . . . . . . . . . . 6 55 5. Link Grouping and Alternates . . . . . . . . . . . . . . . . . 7 56 5.1. The 'group' Attribute . . . . . . . . . . . . . . . . . . 7 57 5.2. The 'alternate' Element . . . . . . . . . . . . . . . . . 7 58 6. Link Decoration . . . . . . . . . . . . . . . . . . . . . . . 8 59 6.1. The 'description' Element . . . . . . . . . . . . . . . . 8 60 6.2. The 'icon' Element . . . . . . . . . . . . . . . . . . . . 8 61 7. Link Relations . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7.1. Hierarchy Links . . . . . . . . . . . . . . . . . . . . . 9 63 7.2. Informational Links . . . . . . . . . . . . . . . . . . . 10 64 7.3. Processing Links . . . . . . . . . . . . . . . . . . . . . 11 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 72 1. Introduction 74 This specification defines extensions to the Atom Syndication Format 75 [I-D.ietf-atompub-format] link and content elements that may be used 76 to express additional metadata about linked resources. 78 2. Notational Conventions 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in BCP 14, [RFC2119] 84 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 85 to uniquely identify XML element names. It uses the following 86 namespace prefix for the indicated namespace URI; 88 {Ed. Note: this namespace MUST be changed to a proper IETF namespace 89 scheme prior to publication} 91 "le": "http://purl.org/atompub/link-extensions/1.0" 93 3. Entity Attributes 95 The following link Entity Attributes may be used to specify metadata 96 about the resource referenced by an atom:link element or atom:content 97 element using the 'src' attribute. 99 3.1. The 'md5' Attribute 101 The 'md5' Attribute specifies a Base64-encoded MD5 digest [RFC1864] 102 of the resource identified by the atom:link/@href or atom:content/@ 103 src attributes. The value of the digest is calculated as specified 104 in [RFC2616] and [RFC1864]. The 'md5' attribute MAY appear as a 105 child of the atom:link and atom:content (using the 'src' attribute) 106 elements. 108 md5 = attribute le:md5 { md5-digest } 110 md5-digest = 112 While MD5 digests are not a guarantee against malicious modifications 113 of a resource, the digest specified may be used as a simple integrity 114 check to verify whether or not the referenced resource has been 115 modified. 117 An example MD5 digest of an enclosed MP3 file 119 123 3.2. The 'etag' Attribute 125 The 'etag' Attribute specifies an Entity Tag [RFC2616] for the 126 resource identified by the atom:link or atom:content element. The 127 'etag' attribute MAY appear as a child of the atom:link and atom: 128 content (using the 'src' attribute) elements. 130 etag = attribute le:etag { entity-tag } 132 entity-tag = [ weak ] opaque-tag 133 weak = "W/" 134 opaque-tag = quoted-string 136 As specified by [RFC2616], Entity Tags are usable for the purpose of 137 comparing multiple entities served from the same resource URI and are 138 typically used in the context of conditional-retrievals of resource 139 representations. 141 An example Entity Tag for an enclosed MP3 file 143 147 3.3. The 'last-modified' Attribute 149 The 'last-modified' Attribute specifies the date and time when the 150 resource identified by the atom:link or atom:content element was last 151 modified as specified by [RFC2616]. The value of the attribute must 152 conform to the HTTP-date construct from [RFC2616]. The 'last- 153 modified' attribute MAY appear as a child of the atom:link and atom: 154 content (using the 'src' attribute) elements. 156 last-modified = attribute le:last-modified { HTTP-date } 158 HTTP-date = rfc1123-date | rfc850-date | asctime-date 159 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 160 rfc850-date = weekday "," SP date2 SP time SP "GMT" 161 asctime-date = wkday SP date3 SP time SP 4DIGIT 162 date1 = 2DIGIT SP month SP 4DIGIT 163 ; day month year (e.g., 02 Jun 1982) 164 date2 = 2DIGIT "-" month "-" 2DIGIT 165 ; day-month-year (e.g., 02-Jun-82) 166 date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 167 ; month day (e.g., Jun 2) 168 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 169 ; 00:00:00 - 23:59:59 170 wkday = "Mon" | "Tue" | "Wed" 171 | "Thu" | "Fri" | "Sat" | "Sun" 172 weekday = "Monday" | "Tuesday" | "Wednesday" 173 | "Thursday" | "Friday" | "Saturday" | "Sunday" 174 month = "Jan" | "Feb" | "Mar" | "Apr" 175 | "May" | "Jun" | "Jul" | "Aug" 176 | "Sep" | "Oct" | "Nov" | "Dec" 178 An example last-modified attribute for an enclosed MP3 file 180 184 3.4. The 'range' Attribute 186 The 'range' Attribute specifies a subset of the resource identified 187 by the atom:link or atom:content element as specified by the standard 188 HTTP Range header defined by [RFC2616]. The 'range' attribute MAY 189 appear as a child of the atom:link and atom:content (using the 'src' 190 attribute) elements. 192 range = attribute le:range { ranges-specifier } 194 ranges-specifier = byte-ranges-specifier 195 byte-ranges-specifier = bytes-unit "=" byte-range-set 196 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) 197 byte-range-spec = first-byte-pos "-" [last-byte-pos] 198 first-byte-pos = 1*DIGIT 199 last-byte-pos = 1*DIGIT 201 The only Range Specifier defined by [RFC2616] is the "bytes" range 202 specifier used to request a specific sequence of bytes from a 203 resource. Other range specifiers MAY be used. Unknown range 204 specifiers SHOULD be ignored. 206 An example range attribute specifying the first 500 bytes of an 207 enclosed MP3 file 209 213 4. Media Descriptors 215 Resources referenced by atom:link and atom:content elements may be 216 optimized for rendering on specific types of devices. 218 4.1. The 'media' Attribute 220 The 'media' attribute MAY be used to identify the types of devices 221 for which a resource referenced by an atom:link or atom:content 222 (using the src attribute) has been targeted. The definition of the 223 media attribute is the same as the 'media' attribute on HTML 224 [W3C.REC-html401-19991224] and XHTML [W3C.REC-xhtml1-20020801] link 225 elements. The 'media' attribute MAY appear as a child of the atom: 226 link and atom:content elements. 228 media = attribute le:media { media-descriptors } 230 The value of the 'media' attribute is a comma separated list of 231 media-descriptor tokens. If not specified, the value of attribute is 232 assumed to be "all". The following lists the standard media- 233 descriptor definitions as specified by [W3C.REC-html401-19991224]. 235 o screen: intended for non-paged computer screens 236 o tty: Intended for media using a fixed-pitch character grid, such 237 as teletypes, terminals, or portable devices with limited display 238 capabilities. 239 o tv: Intended for television-type devices (low resolution, color, 240 limited scrollability). 241 o projection: Intended for projectors. 242 o handheld: Intended for handheld devices (small screen, monochrome, 243 bitmapped graphics, limited bandwidth). 244 o print: Intended for paged, opaque material and for documents 245 viewed on screen in print preview mode. 246 o braille: Intended for braille tactile feedback devices. 247 o aural: Intended for speech synthesizers. 248 o all: Suitable for all devices. 250 Two alternate atom:link elements respectively targeted at screen and 251 handheld devices 253 256 260 5. Link Grouping and Alternates 262 The Link Grouping and Alternate mechanisms defined below make it 263 possible to group related atom:link elements into logical sets or to 264 identify alternate IRI's (e.g. mirrors) for linked resources. 266 5.1. The 'group' Attribute 268 The 'group' Attribute MAY appear as a child of atom:link elements and 269 MAY be used to group associated links together into a logical set of 270 mutually-exclusive options. The value of the attribute is a case- 271 insensitive opaque text string. Link elements with 'group' 272 attributes specifying the same value are considered to belong to the 273 same logical set. 275 group = attribute le:group { text } 277 The following illustrates an example of how the 'group' attribute may 278 be used to identify alternate encodings of the same enclosed audio 279 content. 281 284 288 5.2. The 'alternate' Element 290 The 'alternate' Element is used to specifying one or more alternative 291 IRI's for the resource identified by an atom:link element. For 292 instance, an enclosure referenced by a link may be downloadable from 293 multiple mirror locations. The 'alternate' Element consists of an 294 IRI and optional language-sensitive text label. Zero or more 295 'alternate' elements MAY appear as children of the atom:link element. 296 The parent link element's 'type', 'length' and 'hreflang' attributes 297 are considered to apply equally to each of the contained 'alternate' 298 elements. 300 alternate = element le:alternate { 301 atomCommonAttributes, 302 attribute href, 303 attribute title?, 304 (undefinedContent) 305 } 307 An example atom:link that specifies two alternate download locations 308 for the enclosed MP3 file 310 313 315 317 319 6. Link Decoration 321 6.1. The 'description' Element 323 The 'description' element is an Atom Text Construct that is used to 324 associate a short, human-readable textual summary with an atom:link 325 element. The element MAY appear as a child of atom:link. 327 description = element le:description { atomTextConstruct } 329 An example atom:link element with an associated description. 331 333 334 My first podcast. Isn't it great! 335 336 338 6.2. The 'icon' Element 340 The 'icon' element identifies an image that provides an iconic visual 341 identification for an atom:link. List the standard atom:icon 342 element, which is used to associate an icon image with Atom Feed 343 Documents, images referenced by the 'icon' element SHOULD have a 344 1-to-1 aspect ratio and be suitable for presentation at a small size. 345 The element MAY contain an optional 'type' attribute whose value 346 specifies the media-type of the referenced icon. 348 icon = element le:icon { 349 atomCommonAttributes, 350 attribute type { media-type }?, 351 (atomURI) 352 } 354 An example atom:link element with an associated PNG icon 356 358 http://example.org/icons/podcast.png 359 361 7. Link Relations 363 This specification adds the following values to the IANA Registry of 364 Link Relations as specified by [I-D.ietf-atompub-format]. 366 7.1. Hierarchy Links 368 The Hierarchy Link Relations may be used to organize Atom Feed and 369 Entry documents into a hierarchical tree. 371 o link[@rel='origin'] : The 'origin' link refers to the logical root 372 of a hierarchical tree of entities. 373 o link[@rel='parent'] : The 'parent' link refers to the logical 374 parent of the current entity in a hierarchical tree of entities. 375 o link[@rel='child'] : The 'child' link refers to a logical 376 subordinate of the current document in a hierarchical tree of 377 entities. 378 o link[@rel='sibling'] : The 'sibling' link refers to a logical 379 sibling of the current document in a hierarchical tree of 380 entities. 382 An example of an Atom document hierarchy 384 385 386 387 ... 388 390 392 394 395 396 397 399 401 403 405 407 408 409 410 412 414 416 7.2. Informational Links 418 {To Be Completed} 420 The following link relations may be used to reference informational 421 resources about the containing Atom Feed or Entry. 423 o link[@rel='help'] : The 'help' link refers to a resource offering 424 help information. 425 o link[@rel='about'] : The 'about' link refers to a resource 426 offering information about the containing Feed or Entry. 428 7.3. Processing Links 430 {To Be Completed} 432 The following link relations may be used to reference resources that 433 clients may use to process the content of an Atom entry. 435 o link[@rel='stylesheet'] : The 'stylesheet' link refers to a 436 stylesheet that may be applied to the content of Atom entries. 437 o link[@rel='transformation'] : The 'transformation' link refers to 438 a resource that may be applied to the content of Atom entries. 440 8. Security Considerations 442 TBD 444 9. IANA Considerations 446 There are no IANA considerations introduced by this specification. 448 10. Acknowledgements 450 TBD 452 11. References 454 [I-D.ietf-atompub-format] 455 Sayre, R. and M. Nottingham, "The Atom Syndication 456 Format", draft-ietf-atompub-format-11 (work in progress), 457 August 2005. 459 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 460 RFC 1864, October 1995. 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 466 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 467 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 469 [W3C.REC-html401-19991224] 470 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 471 Specification", W3C REC REC-html401-19991224, 472 December 1999. 474 [W3C.REC-xhtml1-20020801] 475 Pemberton, S., "XHTML[TM] 1.0 The Extensible HyperText 476 Markup Language (Second Edition)", W3C REC REC-xhtml1- 477 20020801, August 2002. 479 [W3C.REC-xml-infoset-20040204] 480 Tobin, R. and J. Cowan, "XML Information Set (Second 481 Edition)", W3C REC REC-xml-infoset-20040204, 482 February 2004. 484 [W3C.REC-xml-names-19990114] 485 Hollander, D., Bray, T., and A. Layman, "Namespaces in 486 XML", W3C REC REC-xml-names-19990114, January 1999. 488 Author's Address 490 James M Snell 492 Phone: 493 Email: jasnell@gmail.com 494 URI: http://snellspace.com 496 Intellectual Property Statement 498 The IETF takes no position regarding the validity or scope of any 499 Intellectual Property Rights or other rights that might be claimed to 500 pertain to the implementation or use of the technology described in 501 this document or the extent to which any license under such rights 502 might or might not be available; nor does it represent that it has 503 made any independent effort to identify any such rights. Information 504 on the procedures with respect to rights in RFC documents can be 505 found in BCP 78 and BCP 79. 507 Copies of IPR disclosures made to the IETF Secretariat and any 508 assurances of licenses to be made available, or the result of an 509 attempt made to obtain a general license or permission for the use of 510 such proprietary rights by implementers or users of this 511 specification can be obtained from the IETF on-line IPR repository at 512 http://www.ietf.org/ipr. 514 The IETF invites any interested party to bring to its attention any 515 copyrights, patents or patent applications, or other proprietary 516 rights that may cover technology that may be required to implement 517 this standard. Please address the information to the IETF at 518 ietf-ipr@ietf.org. 520 Disclaimer of Validity 522 This document and the information contained herein are provided on an 523 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 524 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 525 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 526 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 527 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 528 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Copyright Statement 532 Copyright (C) The Internet Society (2005). This document is subject 533 to the rights, licenses and restrictions contained in BCP 78, and 534 except as set forth therein, the authors retain all their rights. 536 Acknowledgment 538 Funding for the RFC Editor function is currently provided by the 539 Internet Society.