Subject: Last Call: 'The Atom Syndication Format' to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 20 Apr 2005 13:05:00 -0400

The IESG has received a request from the Atom Publishing Format and Protocol 
WG to consider the following document:

- 'The Atom Syndication Format '
   <draft-ietf-atompub-format-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-05-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Apr 2005 19:33:17 +0100

>http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt
In general the document looks good to me. Some minor comments (and few 
questions), mostly nitpicking below:

 >3.1.1.1  Text
 >
 >   Example atom:title with text content:
 >
 >   ...
 >   <title type="text">
 >     Less: &lt;
 >   </title>
 >   ...
 >
 >   If the value is "text", the content of the Text construct MUST NOT
 >   contain child elements.  Such text is intended to be presented to
 >   humans in a readable fashion.  Thus, Atom Processors MAY collapse
 >   white-space (including line-breaks),

Ok, maybe it is just me, but what does it mean to "collapse 
white-space"? Does this mean to replace FWS (in RFC 2822 sense) with a 
single space?

 > and display the text using
 >   typographic techniques such as justification and proportional fonts.

 >4.1.3.3  Processing Model
...
 >   2.  If the value of "type" is "html", the content of atom:content
 >       MUST NOT contain child elements, and SHOULD be suitable for
 >       handling as HTML [HTML].  The HTML markup must be escaped; for

Should the "must" be changed to MUST here?

 >       example, "<br>" as "&lt;br>".  The HTML markup SHOULD be such
 >       that it could validly appear directly within an HTML <DIV>
 >       element.  Atom Processors that display the content MAY use the
 >       markup to aid in displaying it.
...
 >   6.  For all other values of "type", the content of atom:content MUST
 >       be a valid Base64 encoding [RFC3548], which when decoded SHOULD

I have to note that the RFC 3548 has 2 base64 alphabets: in section 3 
and in section 4. You probably want the more common one in section 3, 
but this has to be stated explicitly.

 >6.3  Software Processing of Foreign Markup
 >
...
 >   When unknown foreign markup is encountered in a Text Contruct or
 >   atom:content element, software SHOULD ignore the markup and process
 >   any text content of foreign elements as though the surrounding markup
 >   were not present.

I reread this paragraph few times and I am still not quite sure what the 
paragraph is trying to say. Is it trying to say "if the content of a 
foreign element looks like XML with unrecognized schema - just strip the 
markup and process the text"?

Regards,
Alexey

---

From: Martin Duerst <[email-masked]>
Date: Fri, 29 Apr 2005 18:17:11 +0900

>Ok, maybe it is just me, but what does it mean to "collapse white-space"? 
Does this mean to replace FWS (in RFC 2822 sense) with a single space?

Making this more precise is definitely desirable. But there is also
an i18n issue: This works fine for languages that use spaces between
words. It doesn't work for languages that don't have spaces between
words (Chinese, Japanese, Thai,...). If Text elements are only used
for short things such as names or titles, that's not a big issue,
the text in question can just be put on a single line. However,
when the texts in question are long, it's a serious issue, and
should be fixed.

 >Should the "must" be changed to MUST here?

Yes, please!

Reading this, I got confused because we have both "Text Construct"
and "Text" as subtitles. I suggest to change the subtitle "Text" to
something like "Text Construct with type='text'" or so. Also, starting
a section with just an example looks weird. Please add an introductory
sentence. Same of course for the parallel subsections.

Regards,    Martin.