Subject: I-D ACTION:draft-ietf-atompub-format-03.txt

From: [email-masked]
Date: Thu, 21 Oct 2004 15:32:18 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.

	Title		: The Atom Syndication Format
	Author(s)	: M. Nottingham, R. Sayre
	Filename	: draft-ietf-atompub-format-03.txt
	Pages		: 32
	Date		: 2004-10-21
	
This document specifies Atom, an XML-based Web content and metadata
   syndication format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-atompub-format-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-atompub-format-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 22 Oct 2004 09:43:17 +1000

>      <id>vemmi://example.org/2003/32397</id>

the vemmi URI scheme is described here:

http://www.rfc-archive.org/getrfc.php?rfc=2122

an odd choice for an <id> URI (albeit it is actually supported with an RFC,
unlike tag:)

e.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 21 Oct 2004 17:05:42 -0700

>an odd choice for an <id> URI (albeit it is actually supported with an RFC,

That's a very nice feature, yes.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Eric Scheid <[email-masked]>
Date: Fri, 22 Oct 2004 10:53:38 +1000

reading the diff, some nits specific to the update...

-----------------------------------------------------

> 3.1.1  "type" Attribute (Text Constructs)
> 
> If the value of "type" is "XHTML", the content of the Text construct MAY
> contain child elements.  The content SHOULD be XHTML text and markup that
> could validly appear directly within an xhtml:div element.  Receiving software
> which displays the content MAY use the markup to aid in displaying it.
> 
while text constructs with @type=HTML 'must be encoded' (shouldn't that be
'MUST be encoded'?), the spec is silent of whether text constructs with
@type=XHTML can/should/not be encoded.

will this be a problem?

(was there discussion and changing the name of this attribute away from
'type'? possibly 'mode'?)

-----------------------------------------------------

> 3.2  Person Constructs
> 
> This specification assigns no significance to the order of appearance of the
> child elements of atom:entry.
> 
copy/paste-o?

-----------------------------------------------------

> 3.5  Link Constructs
> 
> A Link construct is an empty element that describes a connection from an Atom
> document to another Web resource.
> 
what is "an Atom document" here - is it this particular instantiation of the
feed, or can it also refer to individual entries (or other constructs?)
within said feed document? That is, is the <link> a connection from the full
document, or is it a connection from the enclosing Atom element (entry,
person, generator?)

-----------------------------------------------------

> The "atom:copyright" element is Text construct that conveys a human-readable
> copyright statement for the feed.  atom:head elements MAY contain an
> atom:copyright element, but  MUST NOT contain more than one.
>
> [[Is the following paragraph bogus amateur lawyering? The first paragraph
> seems sufficient.]]
> 
> The atom:copyright element may be assumed to apply to all entries contained
> by the feed except those entries which contain atom:copyright elements. The
> atom:copyright element MUST, if present, be considered to apply to the feed
> as a collection of entries.

This paragraph is making two points: (a) the precedence of entry/copyright
over head/copyright, and (b) the continuing applicability of head/copyright
to the collection of entries (even if every entry has it's own copyright
element). Both are good points worth making.

-----------------------------------------------------

> 5.9  "atom:summary" Element
>
> atom:entry elements MUST contain an atom:summary element in any of
>  the following cases:
>
>  o  the atom:entry contains content which is encoded in Base64; i.e.
>     the "type" attribute of atom:content is a MIME media type
>     [RFC2045] and does not begin with "text/" nor end with "+xml".

We've changed the semantics/syntax of content/@type to include TEXT, HTML,
and XHTML as special meaning tokens, and of course entries with content of
of any of those three types don't "require" atom/summary. This makes the
above case logically inconsistent with the "i.e." assertion.

-----------------------------------------------------

e.

---

From: Graham <[email-masked]>
Date: Fri, 22 Oct 2004 19:40:22 +0100

I see the wording of atom:origin is still nonsense:

    The "atom:origin" element's content conveys the original source of
    the entry; e.g., the feed where the entry was first published.

    If the source is an Atom Feed Document, then the content of 
atom:origin
    MUST be the same, character-for-character, as [etc]

But there's no "If not...". I think it's meant to imply that you only 
ever use atom:origin when the source is an Atom Feed Document, in which 
case the "If the source is an Atom Feed Document" needs to be in the 
first paragraph.

eg:
    The "atom:origin" element's content conveys the original source of
    the entry when the source is an Atom Feed Document; e.g., the feed 
where the entry
    was first published.

    The content of atom:origin MUST be the same, 
character-for-character, as [etc]

Is that the intended meaning? (The "e.g." probably then needs changing 
to "i.e")

Graham

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 22 Oct 2004 13:03:59 -0700

At 7:40 PM +0100 10/22/04, Graham wrote:
>    If the source is an Atom Feed Document, then the content of atom:origin
>But there's no "If not...". I think it's meant to imply that you 
>only ever use atom:origin when the source is an Atom Feed Document, 
>in which case the "If the source is an Atom Feed Document" needs to 
>be in the first paragraph.
>
>eg:
>    the entry when the source is an Atom Feed Document; e.g., the 
>feed where the entry
>    was first published.
>
>Is that the intended meaning?

That sounds right to me from looking at the discussion.

>  (The "e.g." probably then needs changing to "i.e")

Or, to make it more clear, "that is".

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Oct 2004 17:38:46 -0400

Thank you for taking the time to inspect.

Graham wrote:
 > I see the wording of atom:origin is still nonsense

Our nonsense fidelity is so high, the atom:origin text survived numerous 
round trips. Anyway, noted. We'll get it next time.

> @type=XHTML can/should/not be encoded.

Definitely a nit, but I agree it is a bit fuzzy. It's implied that XHTML 
Text constructs are not encoded since it is allowed to have child elements.

>>child elements of atom:entry.

Yes.

> what is "an Atom document" here 

Atom Documents are described in section 2. I suppose it should be 
capitalized here. The exact relation would be more obvious if we decided 
just where properties go.

>>[[Is the following paragraph bogus amateur lawyering? The first paragraph
...
> element). Both are good points worth making.

Both good points worth making when writing copyright laws. IMHO, it is 
sufficient to say that that head/copyright applies to the feed, while 
entry/copyright applies to the entry. Copyright concerns about collected 
works are for the courts.

> above case logically inconsistent with the "i.e." assertion. 

This comment seems to be incorrect. Or maybe I just don't get it. Show 
me an example if that's the case.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sat, 23 Oct 2004 08:30:57 +1000

> me an example if that's the case.

you're right, I mis-read. The TEXT/HTML/XHTML @type values are not MIME
media types, and thus not covered by the final clause.

e.