The Atom Audience Extension
draft-norris-atompub-audience-00.txt

Abstract

TBD

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on April 17, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Notational Conventions
3.  The 'atom:to' element
4.  The 'atom:cc' element
5.  The 'atom:bcc' element
6.  IRI's and the 'xml:base' Attribute
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgements
10.  Normative References
§  Author's Address

1.  Introduction

TBD

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)

This specification uses XML Namespaces [W3C.REC‑xml‑names‑19990114] (Hollander, D., Bray, T., and A. Layman, “Namespaces in XML,” January 1999.) to uniquely identify XML element names. It uses the following namespace prefix for the indicated namespace URI;

 "atom": "http://www.w3.org/2005/Atom"

3.  The 'atom:to' element

The atom:to element MAY be used as the child of an atom:entry element to identify an intended redistribution target for the atom:entry. The value of the atom:to element MUST be an IRI. Processors that are redistributing copies of an atom:entry, SHOULD NOT remove any contained atom:to elements from the redistributed copy.

  to = element atom:to {
    atomCommonAttributes,
    (atomUri | "*")
  }

An atom:entry element MAY contain any number of atom:to elements, but MUST NOT contain more than one with the same IRI value as sibling atom:to, atom:cc and atom:bcc elements.

The value "*" MAY be used to indicate that the entry is intended to be redistributed to everyone.

Processors that encounter IRI values in atom:to elements that cannot be resolved to a entity to which the atom:entry can be redistributed MUST NOT stop processing the entry. However, such processors MAY signal an error or a warning to the client indicating that the IRI is being ignored.

  <feed xmlns="http://www.w3.org/2005/Atom">
     ...
     <entry>
       ...
       <to>*</to>
       <to>acct:john.doe@example.org</to>
       <to>acct:jane.doe@example.org</to>
       ...
     </entry>
     ...
  </feed>

4.  The 'atom:cc' element

The atom:cc element MAY be used as the child of an atom:entry element to identify an intended redistribution target for the atom:entry. The value of the atom:cc element MUST be an IRI. Processors that are redistributing copies of an atom:entry, SHOULD NOT remove any contained atom:cc elements from the redistributed copy.

  cc = element atom:cc {
    atomCommonAttributes,
    (atomUri | "*")
  }

An atom:entry element MAY contain any number of atom:cc elements, but MUST NOT contain more than one with the same IRI value as sibling atom:to, atom:cc and atom:bcc elements.

The value "*" MAY be used to indicate that the entry is intended to be redistributed to everyone.

Processors that encounter IRI values in atom:cc elements that cannot be resolved to a entity to which the atom:entry can be redistributed MUST NOT stop processing the entry. However, such processors MAY signal an error or a warning to the client indicating that the IRI is being ignored.

  <feed xmlns="http://www.w3.org/2005/Atom">
     ...
     <entry>
       ...
       <to>*</to>
       <cc>acct:john.doe@example.org</cc>
       <cc>acct:jane.doe@example.org</cc>
       ...
     </entry>
     ...
  </feed>

5.  The 'atom:bcc' element

The atom:bcc element MAY be used as the child of an atom:entry element to identify an intended redistribution target for the atom:entry. The value of the atom:to element MUST be an IRI. Processors that are redistributing copies of an atom:entry, MUST remove all contained atom:bcc elements from the redistributed copy. When redistributing an atom:entry containing atom:bcc elements, the processor MAY include an empty atom:bcc element within the redistributed copy as an indication to recipients that copies have been sent to an undisclosed set of recipients.

  bcc = element atom:bcc {
    atomCommonAttributes,
    (atomUri)
  }

An atom:entry element MAY contain any number of atom:bcc elements, but MUST NOT contain more than one with the same IRI value as sibling atom:to, atom:cc or atom:bcc elements.

Processors MUST ignore atom:bcc elements that use the reserved "*" value.

Processors that encounter IRI values in atom:bcc elements that cannot be resolved to a entity to which the atom:entry can be redistributed MUST NOT stop processing the entry. However, such processors MAY signal an error or a warning to the client indicating that the IRI is being ignored.

  <feed xmlns="http://www.w3.org/2005/Atom">
     ...
     <entry>
       ...
       <to>acct:john.doe@example.org</to>
       <bcc>acct:jane.doe@example.org</bcc>
       ...
     </entry>
     ...
  </feed>

6.  IRI's and the 'xml:base' Attribute

The atom:to and atom:bcc elements use IRIs [RFC3987] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.). Every URI [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) is also an IRI, so a URI may be used as the value of these elements. When an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of [RFC3987] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.).

The atom:to and atom:bcc elements MAY have an xml:base attribute [W3C.REC‑xmlbase‑20010627] (Marsh, J., “XML Base,” June 2001.). When xml:base is used, it serves the function described in section 5.1.1 of [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.), establishing the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

7.  Security Considerations

TBD

8.  IANA Considerations

TBD

9.  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.

10. Normative References

Author's Address