idnits 2.17.1 draft-snell-atompub-link-extensions-02.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 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 517. ** 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 (January 24, 2006) is 6659 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 474, 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 January 24, 2006 4 Expires: July 28, 2006 6 Atom Syndication Format Link Extensions 7 draft-snell-atompub-link-extensions-02.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 July 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . 8 57 5.2. The 'alternate' Element . . . . . . . . . . . . . . . . . 8 58 6. Indexing and Automated Downloads . . . . . . . . . . . . . . . 9 59 6.1. The 'le:follow' attribute . . . . . . . . . . . . . . . . 9 60 6.2. The 'le:index' attribute . . . . . . . . . . . . . . . . . 10 61 6.3. The 'le:archive' attribute . . . . . . . . . . . . . . . . 10 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 This specification defines extensions to the Atom Syndication Format 72 [RFC4287] link and content elements that may be used to express 73 additional metadata about linked resources. 75 2. Notational Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in BCP 14, [RFC2119] 81 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 82 to uniquely identify XML element names. It uses the following 83 namespace prefix for the indicated namespace URI; 85 {Ed. Note: this namespace MUST be changed to a proper IETF namespace 86 scheme prior to publication} 88 "le": "http://purl.org/atompub/link-extensions/1.0" 90 3. Entity Attributes 92 The following link Entity Attributes may be used to specify metadata 93 about the resource referenced by an atom:link element or atom:content 94 element using the 'src' attribute. The attributes are designed to 95 closely correlate with existing HTTP [RFC2616] mechanisms used to 96 perform conditional operations, detecting resource modifications and 97 requesting ranges. 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 may have 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 screen 236 intended for non-paged computer screens 238 tty 239 intended for media using a fixed-pitch character 240 grid, such as teletypes, terminals, or portable 241 devices with limited display capabilities. 243 tv 244 intended for television-type devices (low-resolution, 245 color, limited scrollability). 247 projection 248 intended for projectors 250 handheld 251 intended for handheld devices (small screen, 252 monochrome, bitmapped graphics, limited bandwidth). 254 print 255 intended for paged, opaque material and for documents 256 viewed on screen in print preview mode 258 braille 259 intended for braille tactile feedback devices. 261 aural 262 intended for speech synthesizers 264 all 265 suitable for all devices 267 Two alternate atom:link elements respectively targeted at screen and 268 handheld devices 270 273 277 5. Link Grouping and Alternates 279 The Link Grouping and Alternate mechanisms defined below make it 280 possible to group related atom:link elements into logical sets or to 281 identify alternate IRI's (e.g. mirrors) for linked resources. 283 5.1. The 'group' Attribute 285 The 'group' Attribute MAY appear as a child of atom:link elements and 286 MAY be used to group associated links together into a logical set of 287 mutually-exclusive options. The value of the attribute is a case- 288 insensitive, opaque text string. Link elements with 'group' 289 attributes specifying the same value are considered to belong to the 290 same logical set. 292 group = attribute le:group { text } 294 The following illustrates an example of how the 'group' attribute may 295 be used to identify alternate encodings of the same enclosed audio 296 content. 298 301 305 Comparison operations on the 'group' attribute are performed using a 306 case-insensitive character-by-character examination. Entity 307 encodings MUST be interpreted as the character they represent. For 308 instance, The value "group" is equivalent to 309 "group", "Group", "GROUP", etc. 311 5.2. The 'alternate' Element 313 The 'alternate' Element is used to specify one or more alternative 314 IRI's for the resource identified by an atom:link element. For 315 instance, an enclosure referenced by a link may be downloadable from 316 multiple mirror locations. The 'alternate' Element consists of an 317 IRI, an optional language-sensitive text label, and an optional 318 'group' attribute used to group associated alternates together into 319 logical sets. Zero or more 'alternate' elements MAY appear as 320 children of the atom:link element. The parent link element's 'type', 321 'length' and 'hreflang' attributes are considered to apply equally to 322 each of the contained 'alternate' elements. 324 alternate = element le:alternate { 325 atomCommonAttributes, 326 attribute href { atomURI }, 327 attribute title { text }?, 328 attribute group { text }? 329 (undefinedContent) 330 } 332 An example atom:link that specifies two alternate download locations 333 for the enclosed MP3 file 335 338 341 344 347 350 352 6. Indexing and Automated Downloads 354 6.1. The 'le:follow' attribute 356 The 'le:follow" attribute indicates whether applications should 357 automatically attempt to follow links and referenced content (e.g., 358 whether or not enclosure links should be automatically downloaded, 359 etc). The value of the attribute is either "yes" or "no". A value 360 of "no" indicates that applications SHOULD NOT attempt to 361 automatically dereference the linked resource -- rather, the 362 application should wait until a user explicitly requests the linked 363 resource to be resolved. 365 For example, 366 368 ... 369 ... 370 373 ... 374 376 The 'le:follow' attribute MAY be contained by atom:link elements and 377 atom:content elements that contain a 'src' attribute. 379 6.2. The 'le:index' attribute 381 The 'le:index' attribute indicates whether applications should index 382 links and referenced content. The value of the attribute is either 383 "yes" or "no". A value of "no" indicates that applications SHOULD 384 NOT index the referenced resource. 386 For the sake of this specification, 'indexing' refers to the practice 387 of parsing and processing the content of a resource for the purpose 388 of populating a database used for searching and other forms of 389 analysis. The intended purpose of using le:index="no" would be for 390 the publisher to indicate their preference that the associated 391 resource not be processed for searching or analysis purposes. 392 394 ... 395 ... 396 399 ... 400 402 The 'le:index' attribute MAY be contained by atom:link elements and 403 atom:content elements containing a 'src' attribute. 405 6.3. The 'le:archive' attribute 407 The 'le:archive' attribute indicates whether applications should 408 archive the targets of links and content references. The value of 409 the attribute is either "yes" or "no". A value of "no" indicate that 410 applications SHOULD NOT archive the referenced resource. 412 For the sake of this specification, 'archiving' refers to the 413 practice of maintain a local copy of a resource as part of a 414 historical record. This is different than the practice of 415 maintaining locally cached copies of a resource for the sake of 416 improving transmission performance and reducing network bandwidth. 417 The intended purpose of using le:archive="no" would be for a 418 publisher to indicate their preference that local copies of the 419 asociated resource not be maintained for archival/historical 420 purposes. 422 424 ... 425 ... 426 429 ... 430 432 The 'le:archive' attribute MAY be contained by atom:link elements and 433 atom:content elements containing a 'src' attribute. 435 7. Security Considerations 437 While the mechanisms defined herein may be used to detect 438 modifications of linked resources, the mechanisms MUST NOT be 439 considered to provide a guarantee against inappropriate modification. 440 Other mechanisms, such as XML Digital Signatures and XML Encryption 441 should be used to properly secure Atom documents. 443 8. IANA Considerations 445 This specification does not introduce any IANA considerations. 447 9. Acknowledgements 449 The author gratefully acknowledges the feedback from the members of 450 the Atom Publishing Format and Protocol working group during the 451 development of this specification. 453 10. References 455 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 456 RFC 1864, October 1995. 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 462 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 463 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 465 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 466 Format", RFC 4287, December 2005. 468 [W3C.REC-html401-19991224] 469 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 470 Specification", W3C REC REC-html401-19991224, 471 December 1999. 473 [W3C.REC-xhtml1-20020801] 474 Pemberton, S., "XHTML[TM] 1.0 The Extensible HyperText 475 Markup Language (Second Edition)", W3C REC REC-xhtml1- 476 20020801, August 2002. 478 [W3C.REC-xml-infoset-20040204] 479 Tobin, R. and J. Cowan, "XML Information Set (Second 480 Edition)", W3C REC REC-xml-infoset-20040204, 481 February 2004. 483 [W3C.REC-xml-names-19990114] 484 Hollander, D., Bray, T., and A. Layman, "Namespaces in 485 XML", W3C REC REC-xml-names-19990114, January 1999. 487 Author's Address 489 James M Snell 491 Phone: 492 Email: jasnell@gmail.com 493 URI: http://snellspace.com 495 Intellectual Property Statement 497 The IETF takes no position regarding the validity or scope of any 498 Intellectual Property Rights or other rights that might be claimed to 499 pertain to the implementation or use of the technology described in 500 this document or the extent to which any license under such rights 501 might or might not be available; nor does it represent that it has 502 made any independent effort to identify any such rights. Information 503 on the procedures with respect to rights in RFC documents can be 504 found in BCP 78 and BCP 79. 506 Copies of IPR disclosures made to the IETF Secretariat and any 507 assurances of licenses to be made available, or the result of an 508 attempt made to obtain a general license or permission for the use of 509 such proprietary rights by implementers or users of this 510 specification can be obtained from the IETF on-line IPR repository at 511 http://www.ietf.org/ipr. 513 The IETF invites any interested party to bring to its attention any 514 copyrights, patents or patent applications, or other proprietary 515 rights that may cover technology that may be required to implement 516 this standard. Please address the information to the IETF at 517 ietf-ipr@ietf.org. 519 Disclaimer of Validity 521 This document and the information contained herein are provided on an 522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 524 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 525 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 526 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Copyright Statement 531 Copyright (C) The Internet Society (2006). This document is subject 532 to the rights, licenses and restrictions contained in BCP 78, and 533 except as set forth therein, the authors retain all their rights. 535 Acknowledgment 537 Funding for the RFC Editor function is currently provided by the 538 Internet Society.