idnits 2.17.1 draft-snell-atompub-author-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 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 454. ** 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 1. If the value of "type" is "text", the content of 'profile' MUST NOT contain child elements. Such text MAY or MAY NOT be intended to be presented to humans in a readable fashion. Thus, Processors MUST NOT collapse white space (including line breaks) or apply any typographic techniques such as justification or proportional fonts. -- 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 (February 22, 2006) is 6638 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: 'MIMEREG' is mentioned on line 176, but not defined == Missing Reference: 'XHTML' is mentioned on line 207, but not defined == Missing Reference: 'RFC3023' is mentioned on line 299, but not defined ** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303) == Missing Reference: 'RFC3548' is mentioned on line 309, but not defined ** Obsolete undefined reference: RFC 3548 (Obsoleted by RFC 4648) == Missing Reference: 'TM' is mentioned on line 411, but not defined == Unused Reference: 'RFC1864' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC4287' is defined on line 402, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft February 22, 2006 4 Expires: August 26, 2006 6 Atom Syndication Format Person Extensions 7 draft-snell-atompub-author-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 August 26, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This specification defines extensions to the Atom Syndication Format 41 Person Construct. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 47 3. Person Profiles . . . . . . . . . . . . . . . . . . . . . . . 3 48 3.1. The 'profile' Element . . . . . . . . . . . . . . . . . . 3 49 3.2. The 'type' attribute . . . . . . . . . . . . . . . . . . . 5 50 3.3. The 'src' attribute . . . . . . . . . . . . . . . . . . . 5 51 3.4. The 'scheme' attribute . . . . . . . . . . . . . . . . . . 5 52 3.5. Processing Model . . . . . . . . . . . . . . . . . . . . . 5 53 4. Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. The 'identity' Element . . . . . . . . . . . . . . . . . . 6 55 4.2. The 'type' attribute . . . . . . . . . . . . . . . . . . . 7 56 4.3. The 'scheme' attribute . . . . . . . . . . . . . . . . . . 7 57 4.4. The 'src' attribute . . . . . . . . . . . . . . . . . . . 7 58 4.5. Processing Model . . . . . . . . . . . . . . . . . . . . . 8 59 5. Contribution Roles . . . . . . . . . . . . . . . . . . . . . . 8 60 5.1. The 'role' Element . . . . . . . . . . . . . . . . . . . . 8 61 5.2. The 'scheme' attribute . . . . . . . . . . . . . . . . . . 9 62 5.3. The 'term' attribute . . . . . . . . . . . . . . . . . . . 9 63 5.4. The 'label' attribute . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 Intellectual Property and Copyright Statements . . . . . . . . . . 12 71 1. Introduction 73 The Atom Person construct provides a limited set of metadata elements 74 for describing individuals or entities who have authored or 75 contributed to a feed or entry. In addition to this core set of 76 data, feed publishers may wish to provide richer descriptions of 77 those individuals. The extensions defined by this specification 78 provide mechanism for expressing rich user profile, identity and 79 contribution roles for an individual author or contributor. 81 2. Notational Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in BCP 14, [RFC2119] 87 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 88 to uniquely identify XML element names. It uses the following 89 namespace prefix for the indicated namespace URI; 91 {Ed. Note: this namespace MUST be changed to a proper IETF namespace 92 scheme prior to publication} 94 "pe": "http://purl.org/atompub/person-extensions/1.0" 96 3. Person Profiles 98 3.1. The 'profile' Element 100 Person Profiles are rich metadata descriptions about an individual 101 author or contributor. Using the 'profile' element, Profiles may be 102 included directly within an Atom Person Construct or referenced 103 externally. 105 inlineTextProfile = element pe:profile { 106 atomCommonAttributes, 107 attribute scheme { atomURI }?, 108 attribute type { "text" | "html" }?, 109 (text)* 110 } 112 inlineXHTMLProfile = element pe:profile { 113 atomCommonAttributes, 114 attribute scheme { atomURI }?, 115 attribute type { "xhtml" }, 116 xhtmlDiv 117 } 119 inlineOtherProfile = element pe:profile { 120 atomCommonAttributes, 121 attribute scheme { atomURI }?, 122 attribute type { atomMediaType }?, 123 (text|anyElement)* 124 } 126 outOfLineProfile = element pe:profile { 127 atomCommonAttributes, 128 attribute scheme { atomURI }?, 129 attribute type { atomMediaType }?, 130 attribute src { atomUri }, 131 empty 132 } 134 profile = inlineTextProfile 135 | inlineXHTMLProfile 136 | inlineOtherProfile 137 | outOfLineProfile 139 An in-line XHTML-based hCard Profile 141 143
144
145 146 John Doe 147 148
Example, Org
149
150
151 153 An out-of-line FOAF Profile 155 159 3.2. The 'type' attribute 161 The 'profile' element 'type' attribute value MUST be either one of 162 'text', 'html', or 'xhtml' or a non-composite MIME media type. If 163 neither the type or src attributes are provided, the value of the 164 'type' attribute MUST be assumed to be 'text'. 166 3.3. The 'src' attribute 168 The 'profile' element MAY contain a 'src' attribute whose value is an 169 IRI reference. If the 'src' attribute is present, the 'profile' 170 element MUST be empty. Atom Processors MAY use the IRI to retrieve 171 the profile and MAY choose to either ignore the remote profile or to 172 present it in a manner different than a profile included directly 173 within the Person Construct. 175 If the "src" attribute is present, the "type" attribute SHOULD be 176 provided and MUST be a MIME media type [MIMEREG], rather than "text", 177 "html", or "xhtml". The value is advisory; that is to say, when the 178 corresponding URI (mapped from an IRI, if necessary) is dereferenced, 179 if the server providing that content also provides a media type, the 180 server-provided media type is authoritative. 182 3.4. The 'scheme' attribute 184 The 'profile' element MAY contain a 'scheme' attribute whose value is 185 an IRI that may be used to provide additional differentiation of the 186 profile scheme. 188 3.5. Processing Model 190 Processors MUST interpret the 'profile' element according to the 191 first applicable rule. 193 1. If the value of "type" is "text", the content of 'profile' MUST 194 NOT contain child elements. Such text MAY or MAY NOT be intended 195 to be presented to humans in a readable fashion. Thus, 196 Processors MUST NOT collapse white space (including line breaks) 197 or apply any typographic techniques such as justification or 198 proportional fonts. 200 2. If the value of "type" is "html", the content of 'profile' MUST 201 NOT contain child elements and SHOULD be suitable for handling as 202 HTML. The HTML markup MUST be escaped; for example, "
" as 203 "<br>". The HTML markup SHOULD be such that it could validly 204 appear directly within an HTML
element. Processors that 205 display the content MAY use the markup to aid in displaying it. 206 3. If the value of "type" is "xhtml", the content of 'profile' MUST 207 be a single XHTML div element [XHTML] and SHOULD be suitable for 208 handling as XHTML. The XHTML div element itself MUST NOT be 209 considered part of the content of the profile. Processors that 210 display the content MAY use the markup to aid in displaying it. 211 The escaped versions of characters such as "&" and ">" represent 212 those characters, not markup. 213 4. If the value of "type" is an XML media type [RFC3023] or ends 214 with "+xml" or "/xml" (case insensitive), the content of 215 'profile' MAY include child elements and SHOULD be suitable for 216 handling as the indicated media type. If the "src" attribute is 217 not provided, this would normally mean that the 'profile' element 218 would contain a single child element that would serve as the root 219 element of the XML document of the indicated type. 220 5. If the value of "type" begins with "text/" (case insensitive), 221 the content of 'profile' MUST NOT contain child elements. 222 6. For all other values of "type", the content of 'profile' MUST be 223 a valid Base64 encoding, as described in [RFC3548], section 3. 224 When decoded, it SHOULD be suitable for handling as the indicated 225 media type. In this case, the characters in the Base64 encoding 226 MAY be preceded and followed in the 'profile' element by white 227 space, and lines are separated by a single newline (U+000A) 228 character. 230 4. Identity 232 4.1. The 'identity' Element 234 The 'identity' element is used to associate an identity token with an 235 Atom Person Construct. 237 inlineIdentity = element pe:identity { 238 atomCommonAttributes, 239 attribute scheme { atomURI }?, 240 attribute type { atomMediaType }, 241 (text)* 242 } 244 outOfLineIdentity = element pe:identity { 245 atomCommonAttributes, 246 attribute scheme { atomURI }?, 247 attribute type { atomMediaType }, 248 attribute src { atomURI }, 249 empty 250 } 252 identity = inlineIdentity 253 | outOfLineIdentity 255 An out-of-line OpenID Identity 257 261 An in-line, Base64-encoded X.509 Identity 263 265 {base64 encoded binary data} 266 268 4.2. The 'type' attribute 270 The 'identity' element 'type' attribute value MUST be a non-composite 271 MIME media type. 273 4.3. The 'scheme' attribute 275 The 'identity' element MAY contain a 'scheme' attribute whose value 276 is an IRI that may be used to provide additional differentiation of 277 the identity scheme. 279 4.4. The 'src' attribute 281 The 'identity' element MAY contain a 'src' attribute whose value is 282 an IRI reference. If the 'src' attribute is present, the 'identity' 283 element MUST be empty. Atom Processors MAY use the IRI to retrieve 284 the identity token and MAY choose to either ignore the remote 285 identity or to present it in a manner different than an identity 286 included directly within the Person Construct. 288 If the "src" attribute is present, the value of the "type" attribute 289 is advisory; that is to say, when the corresponding URI (mapped from 290 an IRI, if necessary) is dereferenced, if the server providing that 291 content also provides a media type, the server-provided media type is 292 authoritative. 294 4.5. Processing Model 296 Processors MUST interpret the 'identity' element according to the 297 first applicable rule. 299 1. If the value of "type" is an XML media type [RFC3023] or ends 300 with "+xml" or "/xml" (case insensitive), the content of 301 'profile' MAY include child elements and SHOULD be suitable for 302 handling as the indicated media type. If the "src" attribute is 303 not provided, this would normally mean that the 'profile' element 304 would contain a single child element that would serve as the root 305 element of the XML document of the indicated type. 306 2. If the value of "type" begins with "text/" (case insensitive), 307 the content of 'profile' MUST NOT contain child elements. 308 3. For all other values of "type", the content of 'profile' MUST be 309 a valid Base64 encoding, as described in [RFC3548], section 3. 310 When decoded, it SHOULD be suitable for handling as the indicated 311 media type. In this case, the characters in the Base64 encoding 312 MAY be preceded and followed in the 'profile' element by white 313 space, and lines are separated by a single newline (U+000A) 314 character. 316 5. Contribution Roles 318 5.1. The 'role' Element 320 The 'role' element may be used to associate a specific contribution 321 role with an Atom Person Construct. Contribution roles are useful to 322 differentiating the different types of contributions (e.g. author, 323 editor, translator, etc) an individual entity may have made to the 324 creation of a feed or entry. 326 role = element pe:role { 327 atomCommonAttributes, 328 attribute scheme { atomURI }?, 329 attribute term { atomURI }, 330 attribute label { text }?, 331 empty 333 } 335 Example atom:contributors using Library of Congress MARC role codes 337 338 John Doe 339 342 343 344 Jane Doe 345 348 349 350 Joe Smith 351 354 356 5.2. The 'scheme' attribute 358 The 'scheme' attribute is an IRI that identifies a role 359 classification scheme. 361 5.3. The 'term' attribute 363 The 'term' attribute is a string that identifies the role associated 364 with the Person construct. 366 5.4. The 'label' attribute 368 The 'label' attribute provides a language-sensitive, human-readable 369 label for display in end-user applications. Entities such as "&" 370 and "<" represent their corresponding characters ("&" and "<", 371 respectively), not markup. 373 6. Security Considerations 375 TBD 377 7. IANA Considerations 378 There are no IANA considerations introduced by this specification. 380 8. Acknowledgements 382 The author gratefully acknowledges the feedback from the members of 383 the Atom Publishing Format and Protocol working group during the 384 development of this specification. In order to maintain structural 385 and semantic alignment with the Atom Syndication Format 386 specification, some portions of the Atom Format specification were 387 copied near verbatim within this specification and adapted to the 388 specific elements defined herein. 390 9. References 392 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 393 RFC 1864, October 1995. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 399 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 400 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 402 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 403 Format", RFC 4287, December 2005. 405 [W3C.REC-html401-19991224] 406 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 407 Specification", W3C REC REC-html401-19991224, 408 December 1999. 410 [W3C.REC-xhtml1-20020801] 411 Pemberton, S., "XHTML[TM] 1.0 The Extensible HyperText 412 Markup Language (Second Edition)", W3C REC REC-xhtml1- 413 20020801, August 2002. 415 [W3C.REC-xml-infoset-20040204] 416 Tobin, R. and J. Cowan, "XML Information Set (Second 417 Edition)", W3C REC REC-xml-infoset-20040204, 418 February 2004. 420 [W3C.REC-xml-names-19990114] 421 Hollander, D., Bray, T., and A. Layman, "Namespaces in 422 XML", W3C REC REC-xml-names-19990114, January 1999. 424 Author's Address 426 James M Snell 428 Phone: 429 Email: jasnell@gmail.com 430 URI: http://snellspace.com 432 Intellectual Property Statement 434 The IETF takes no position regarding the validity or scope of any 435 Intellectual Property Rights or other rights that might be claimed to 436 pertain to the implementation or use of the technology described in 437 this document or the extent to which any license under such rights 438 might or might not be available; nor does it represent that it has 439 made any independent effort to identify any such rights. Information 440 on the procedures with respect to rights in RFC documents can be 441 found in BCP 78 and BCP 79. 443 Copies of IPR disclosures made to the IETF Secretariat and any 444 assurances of licenses to be made available, or the result of an 445 attempt made to obtain a general license or permission for the use of 446 such proprietary rights by implementers or users of this 447 specification can be obtained from the IETF on-line IPR repository at 448 http://www.ietf.org/ipr. 450 The IETF invites any interested party to bring to its attention any 451 copyrights, patents or patent applications, or other proprietary 452 rights that may cover technology that may be required to implement 453 this standard. Please address the information to the IETF at 454 ietf-ipr@ietf.org. 456 Disclaimer of Validity 458 This document and the information contained herein are provided on an 459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 461 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 462 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 463 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Copyright Statement 468 Copyright (C) The Internet Society (2006). This document is subject 469 to the rights, licenses and restrictions contained in BCP 78, and 470 except as set forth therein, the authors retain all their rights. 472 Acknowledgment 474 Funding for the RFC Editor function is currently provided by the 475 Internet Society.