Network Working Group J. Snell
Internet-Draft February 22, 2006
Expires: August 26, 2006
Atom Syndication Format Person Extensions
draft-snell-atompub-author-extensions-00.txt
Status of this Memo
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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This specification defines extensions to the Atom Syndication Format
Person Construct.
Snell Expires August 26, 2006 [Page 1]
Internet-Draft Atom Person Extensions February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Person Profiles . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The 'profile' Element . . . . . . . . . . . . . . . . . . 3
3.2. The 'type' attribute . . . . . . . . . . . . . . . . . . . 5
3.3. The 'src' attribute . . . . . . . . . . . . . . . . . . . 5
3.4. The 'scheme' attribute . . . . . . . . . . . . . . . . . . 5
3.5. Processing Model . . . . . . . . . . . . . . . . . . . . . 5
4. Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The 'identity' Element . . . . . . . . . . . . . . . . . . 6
4.2. The 'type' attribute . . . . . . . . . . . . . . . . . . . 7
4.3. The 'scheme' attribute . . . . . . . . . . . . . . . . . . 7
4.4. The 'src' attribute . . . . . . . . . . . . . . . . . . . 7
4.5. Processing Model . . . . . . . . . . . . . . . . . . . . . 8
5. Contribution Roles . . . . . . . . . . . . . . . . . . . . . . 8
5.1. The 'role' Element . . . . . . . . . . . . . . . . . . . . 8
5.2. The 'scheme' attribute . . . . . . . . . . . . . . . . . . 9
5.3. The 'term' attribute . . . . . . . . . . . . . . . . . . . 9
5.4. The 'label' attribute . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Snell Expires August 26, 2006 [Page 2]
Internet-Draft Atom Person Extensions February 2006
1. Introduction
The Atom Person construct provides a limited set of metadata elements
for describing individuals or entities who have authored or
contributed to a feed or entry. In addition to this core set of
data, feed publishers may wish to provide richer descriptions of
those individuals. The extensions defined by this specification
provide mechanism for expressing rich user profile, identity and
contribution roles for an individual author or contributor.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119]
This specification uses XML Namespaces [W3C.REC-xml-names-19990114]
to uniquely identify XML element names. It uses the following
namespace prefix for the indicated namespace URI;
{Ed. Note: this namespace MUST be changed to a proper IETF namespace
scheme prior to publication}
"pe": "http://purl.org/atompub/person-extensions/1.0"
3. Person Profiles
3.1. The 'profile' Element
Person Profiles are rich metadata descriptions about an individual
author or contributor. Using the 'profile' element, Profiles may be
included directly within an Atom Person Construct or referenced
externally.
Snell Expires August 26, 2006 [Page 3]
Internet-Draft Atom Person Extensions February 2006
inlineTextProfile = element pe:profile {
atomCommonAttributes,
attribute scheme { atomURI }?,
attribute type { "text" | "html" }?,
(text)*
}
inlineXHTMLProfile = element pe:profile {
atomCommonAttributes,
attribute scheme { atomURI }?,
attribute type { "xhtml" },
xhtmlDiv
}
inlineOtherProfile = element pe:profile {
atomCommonAttributes,
attribute scheme { atomURI }?,
attribute type { atomMediaType }?,
(text|anyElement)*
}
outOfLineProfile = element pe:profile {
atomCommonAttributes,
attribute scheme { atomURI }?,
attribute type { atomMediaType }?,
attribute src { atomUri },
empty
}
profile = inlineTextProfile
| inlineXHTMLProfile
| inlineOtherProfile
| outOfLineProfile
An in-line XHTML-based hCard Profile
<pe:profile type="xhtml"
scheme="http://microformats.org/wiki/hcard">
<div xmlns="http://www.w3.org/1999/xhtml">
<div class="vcard">
<a class="url fn" href="http://example.org/">
John Doe
</a>
<div class="org">Example, Org</div>
<div>
</div>
</pe:profile>
Snell Expires August 26, 2006 [Page 4]
Internet-Draft Atom Person Extensions February 2006
An out-of-line FOAF Profile
<pe:profile type="application/rdf+xml"
src="http://example.org/johndoe.foaf"
scheme="http://xmlns.com/foaf/0.1/" />
3.2. The 'type' attribute
The 'profile' element 'type' attribute value MUST be either one of
'text', 'html', or 'xhtml' or a non-composite MIME media type. If
neither the type or src attributes are provided, the value of the
'type' attribute MUST be assumed to be 'text'.
3.3. The 'src' attribute
The 'profile' element MAY contain a 'src' attribute whose value is an
IRI reference. If the 'src' attribute is present, the 'profile'
element MUST be empty. Atom Processors MAY use the IRI to retrieve
the profile and MAY choose to either ignore the remote profile or to
present it in a manner different than a profile included directly
within the Person Construct.
If the "src" attribute is present, the "type" attribute SHOULD be
provided and MUST be a MIME media type [MIMEREG], rather than "text",
"html", or "xhtml". The value is advisory; that is to say, when the
corresponding URI (mapped from an IRI, if necessary) is dereferenced,
if the server providing that content also provides a media type, the
server-provided media type is authoritative.
3.4. The 'scheme' attribute
The 'profile' element MAY contain a 'scheme' attribute whose value is
an IRI that may be used to provide additional differentiation of the
profile scheme.
3.5. Processing Model
Processors MUST interpret the 'profile' element according to the
first applicable rule.
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.
Snell Expires August 26, 2006 [Page 5]
Internet-Draft Atom Person Extensions February 2006
2. If the value of "type" is "html", the content of 'profile' MUST
NOT contain child elements and SHOULD be suitable for handling as
HTML. The HTML markup MUST be escaped; for example, "<br>" as
"<br>". The HTML markup SHOULD be such that it could validly
appear directly within an HTML <DIV> element. Processors that
display the content MAY use the markup to aid in displaying it.
3. If the value of "type" is "xhtml", the content of 'profile' MUST
be a single XHTML div element [XHTML] and SHOULD be suitable for
handling as XHTML. The XHTML div element itself MUST NOT be
considered part of the content of the profile. Processors that
display the content MAY use the markup to aid in displaying it.
The escaped versions of characters such as "&" and ">" represent
those characters, not markup.
4. If the value of "type" is an XML media type [RFC3023] or ends
with "+xml" or "/xml" (case insensitive), the content of
'profile' MAY include child elements and SHOULD be suitable for
handling as the indicated media type. If the "src" attribute is
not provided, this would normally mean that the 'profile' element
would contain a single child element that would serve as the root
element of the XML document of the indicated type.
5. If the value of "type" begins with "text/" (case insensitive),
the content of 'profile' MUST NOT contain child elements.
6. For all other values of "type", the content of 'profile' MUST be
a valid Base64 encoding, as described in [RFC3548], section 3.
When decoded, it SHOULD be suitable for handling as the indicated
media type. In this case, the characters in the Base64 encoding
MAY be preceded and followed in the 'profile' element by white
space, and lines are separated by a single newline (U+000A)
character.
4. Identity
4.1. The 'identity' Element
The 'identity' element is used to associate an identity token with an
Atom Person Construct.
Snell Expires August 26, 2006 [Page 6]
Internet-Draft Atom Person Extensions February 2006
inlineIdentity = element pe:identity {
atomCommonAttributes,
attribute scheme { atomURI }?,
attribute type { atomMediaType },
(text)*
}
outOfLineIdentity = element pe:identity {
atomCommonAttributes,
attribute scheme { atomURI }?,
attribute type { atomMediaType },
attribute src { atomURI },
empty
}
identity = inlineIdentity
| outOfLineIdentity
An out-of-line OpenID Identity
<pe:identity
scheme="http://openid.net"
href="http://www.example.org" />
An in-line, Base64-encoded X.509 Identity
<pe:identity
type="application/x509-user-cert">
{base64 encoded binary data}
</pe:identity>
4.2. The 'type' attribute
The 'identity' element 'type' attribute value MUST be a non-composite
MIME media type.
4.3. The 'scheme' attribute
The 'identity' element MAY contain a 'scheme' attribute whose value
is an IRI that may be used to provide additional differentiation of
the identity scheme.
4.4. The 'src' attribute
The 'identity' element MAY contain a 'src' attribute whose value is
an IRI reference. If the 'src' attribute is present, the 'identity'
element MUST be empty. Atom Processors MAY use the IRI to retrieve
the identity token and MAY choose to either ignore the remote
Snell Expires August 26, 2006 [Page 7]
Internet-Draft Atom Person Extensions February 2006
identity or to present it in a manner different than an identity
included directly within the Person Construct.
If the "src" attribute is present, the value of the "type" attribute
is advisory; that is to say, when the corresponding URI (mapped from
an IRI, if necessary) is dereferenced, if the server providing that
content also provides a media type, the server-provided media type is
authoritative.
4.5. Processing Model
Processors MUST interpret the 'identity' element according to the
first applicable rule.
1. If the value of "type" is an XML media type [RFC3023] or ends
with "+xml" or "/xml" (case insensitive), the content of
'profile' MAY include child elements and SHOULD be suitable for
handling as the indicated media type. If the "src" attribute is
not provided, this would normally mean that the 'profile' element
would contain a single child element that would serve as the root
element of the XML document of the indicated type.
2. If the value of "type" begins with "text/" (case insensitive),
the content of 'profile' MUST NOT contain child elements.
3. For all other values of "type", the content of 'profile' MUST be
a valid Base64 encoding, as described in [RFC3548], section 3.
When decoded, it SHOULD be suitable for handling as the indicated
media type. In this case, the characters in the Base64 encoding
MAY be preceded and followed in the 'profile' element by white
space, and lines are separated by a single newline (U+000A)
character.
5. Contribution Roles
5.1. The 'role' Element
The 'role' element may be used to associate a specific contribution
role with an Atom Person Construct. Contribution roles are useful to
differentiating the different types of contributions (e.g. author,
editor, translator, etc) an individual entity may have made to the
creation of a feed or entry.
role = element pe:role {
atomCommonAttributes,
attribute scheme { atomURI }?,
attribute term { atomURI },
attribute label { text }?,
empty
Snell Expires August 26, 2006 [Page 8]
Internet-Draft Atom Person Extensions February 2006
}
Example atom:contributors using Library of Congress MARC role codes
<contributor>
<name>John Doe</name>
<pe:role scheme="http://www.loc.gov/marc"
term="aqt"
label="Cited author" />
</contributor>
<contributor>
<name>Jane Doe</name>
<pe:role scheme="http://www.loc.gov/marc"
term="edt"
label="Editor" />
</contributor>
<contributor>
<name>Joe Smith</name>
<pe:role scheme="http://www.loc.gov/marc"
term="trc"
label="Transcriber" />
</contributor>
5.2. The 'scheme' attribute
The 'scheme' attribute is an IRI that identifies a role
classification scheme.
5.3. The 'term' attribute
The 'term' attribute is a string that identifies the role associated
with the Person construct.
5.4. The 'label' attribute
The 'label' attribute provides a language-sensitive, human-readable
label for display in end-user applications. Entities such as "&"
and "<" represent their corresponding characters ("&" and "<",
respectively), not markup.
6. Security Considerations
TBD
7. IANA Considerations
Snell Expires August 26, 2006 [Page 9]
Internet-Draft Atom Person Extensions February 2006
There are no IANA considerations introduced by this specification.
8. Acknowledgements
The author gratefully acknowledges the feedback from the members of
the Atom Publishing Format and Protocol working group during the
development of this specification. In order to maintain structural
and semantic alignment with the Atom Syndication Format
specification, some portions of the Atom Format specification were
copied near verbatim within this specification and adapted to the
specific elements defined herein.
9. References
[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
RFC 1864, October 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
Format", RFC 4287, December 2005.
[W3C.REC-html401-19991224]
Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01
Specification", W3C REC REC-html401-19991224,
December 1999.
[W3C.REC-xhtml1-20020801]
Pemberton, S., "XHTML[TM] 1.0 The Extensible HyperText
Markup Language (Second Edition)", W3C REC REC-xhtml1-
20020801, August 2002.
[W3C.REC-xml-infoset-20040204]
Tobin, R. and J. Cowan, "XML Information Set (Second
Edition)", W3C REC REC-xml-infoset-20040204,
February 2004.
[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", W3C REC REC-xml-names-19990114, January 1999.
Snell Expires August 26, 2006 [Page 10]
Internet-Draft Atom Person Extensions February 2006
Author's Address
James M Snell
Phone:
Email: jasnell@gmail.com
URI: http://snellspace.com
Snell Expires August 26, 2006 [Page 11]
Internet-Draft Atom Person Extensions February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Snell Expires August 26, 2006 [Page 12]