[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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
       "&lt;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 "&amp;"
   and "&lt;" 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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/