Subject: Updated issues list

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Mar 2005 16:05:41 +0100

Hi,

I just reviewed my -05 issues list, and updated it based on the changes 
in -06:

05-C02, 3.1.1, "type" attribute

<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1>
-06: 
<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1>, 
examples updated

Suggested examples for TEXT, HTML and XHTML: a title containing the 
string "Less: <", where the less sign displays emphasized when possible..

<atomTitle type="TEXT">
   Less: &lt;
</atomTitle>

<atomTitle type="HTML">
   Less: &lt;em> &amp;lt; &lt;/em>
</atomTitle>

<atomTitle type="XHTML" 
xmlns:xhtml="http://www.w3.org/1999/xhtml"><xhtml:div>
   Less: <xhtml:em> &lt; </xhtml:em>
</xhtml:div></atomTitle>

(hope I got these right).

05-C05, 4.15.3 processing model

<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3>
-06: 
<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.4.1.3.3>

"If the value of "type" ends with "+xml" or "/xml", the content of 
atom:content may include child elements, and SHOULD be suitable for 
handling by software that knows the indicated media type. If the "src" 
attribute is not provided, this would normally mean that the 
"atom:content" element would contain a single child element which would 
serve as the root element of the XML document of the indicated type."

The statement about the "src" attribute seems to be unnecessary given 
the SHOULD-level requirement to have local content (thus no "src" 
attribute).

"If the value of "type" begins with "text/" the content of atom:content 
MUST NOT contain child elements."

See 4.15.2: so is this a SHOULD or a MUST?

Update -06: I'm still confused by the text. For instance:

- is it intentional that 4.1.3.3 says ``If the value of "type" ends with 
"+xml" or "/xml"'', while 4.1.3.2 used ``If the value of type begins 
with "text/" or ends with "+xml"''?

- also, if content for +xml SHOULD be local (4.1.3.2), why does 4.1.3.3. 
point 4, make statements about situations where it comes with @src 
attribute? Maybe it's not a SHOULD requirement after all?

05-E02, Notational Conventions

<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#RELAX-NG>

I think this should come with the following URL: 
<http://www.oasis-open.org/committees/relax-ng/spec-20011203.html>

Update -06: I think it would be good if all W3C references came with URLs.

05-E03, Notational Conventions

"A collected schema appears in an informative appendix."

(refer directly by section/appendix number). Same for some other 
intra-document references.

05-E05, 3.2.2 atom:uri

"The content of atom:uri in a Person construct MUST be a URI reference 
[RFC2396bis]."
06: 
<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.2>

Directly point to RFC3986's section (here: 4.1).

Update -06: I still think that spelling out the section number will make 
it easier to actually locate the definition.

05-E06, 3.2.3 atom:email

http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.3

"Its content MUST be an e-mail address [RFC2822]."

Again, please refer directly to the definition. In this case, it seems 
to be section 3.4.1 (addr-spec production).

05-E08, 4.6.2 rel attribute

<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.6.2>
06: 
<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.4.2.9.2>

If we use (A)BNF syntax, the spec needs to say so and reference the 
definition normatively (for instance, RFC2234).

"...same name registered within the IANA Registry of Link Relations 
Section 9, and..."

Put the section reference into brackets.

05-E12, 11 references

<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.references>
06: 
<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.references>

Here's a producedural question: if we have normative references to the 
protocol and the feed discovery document, the spec won't get published 
until those are done, too. Is everybody aware of that?

Update -06: we still have a normative reference to the feed discovery 
spec, which, according to <http://tools.ietf.org/wg/atompub/>, has 
expired. If this reference is expected to stay in, we'll have to 
actually finish that spec as well :-)

Best regards, Julian

---

From: Eric Scheid <[email-masked]>
Date: Mon, 21 Mar 2005 02:42:03 +1100

On 21/3/05 2:05 AM, "Julian Reschke" <[email-masked]> wrote:

> until those are done, too.

+1

> actually finish that spec as well :-)

+1

---

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Mar 2005 17:21:18 +0100

..and here's a set of *new* issues I found while re-reading the draft...:

06-C01, 3.1.1 "type" Attribute

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1>

This has been mentioned before...: as far as I can tell, it's far easier 
for recipients to process "xhtml" compared to "html" (no tag-soup parser 
needed), thus *any* kind of change that encourages "xhtml" would be 
appreciated.

06-C02, 3.1.1 "type" Attribute

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1>

Here's a question. Is this...:

<summary type="html">
   overlapping &lt;b>markup &lt;>is&lt;/b> bad&lt;/i>.
</summary>

legal Atom? As far as I can tell, here we have a SHOULD level 
requirement to only transport well-formed HTML4 content, right?

06-C03, 3.3 Date Constructs

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.3>

As others have pointed out, the regexp is incorrect ("-" characters in 
full-date part are missing). Also, I'm not sure whether it requires the 
timezone information; if it doesn't, this isn't what RFC3339 defines. In 
general, I find RFC3339 much easier to read:

--snip--
    date-fullyear   = 4DIGIT
    date-month      = 2DIGIT  ; 01-12
    date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                              ; month/year
    time-hour       = 2DIGIT  ; 00-23
    time-minute     = 2DIGIT  ; 00-59
    time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                              ; rules
    time-secfrac    = "." 1*DIGIT
    time-numoffset  = ("+" / "-") time-hour ":" time-minute
    time-offset     = "Z" / time-numoffset

    partial-time    = time-hour ":" time-minute ":" time-second
                      [time-secfrac]
    full-date       = date-fullyear "-" date-month "-" date-mday
    full-time       = partial-time time-offset

    date-time       = full-date "T" full-time
--snip--

06-E01, 1.2 Example

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.1.2>

Is it intentional that the example is inconsistently indented?

06-E02, 1.3 Notational Conventions

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.1.3>

...speaks about namespace prefixe*s* being defined; but then only 
defines a single one.

06-E03, 5.1 Digital Signatures

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.5.1>

s/namespace IRI/namespace URI/ (or "namespace name")

06-E04, 6.2 Extensions To the Atom Vocabulary

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.6.2>

--snip--
considered "foreign "markup".
--snip--

(quoting).

06-E05, 8.1 HTML and XHTML Content

<http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.8.1>

"See the security sections of RFC 2854 and HTML 4.01 for guidance."

(use proper references)

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Sun, 20 Mar 2005 13:42:13 -0500

Thanks for the close reading. Comments inline.

> needed), thus *any* kind of change that encourages "xhtml" would be 

I've heard client and server implementors take every possible position 
on the matter. I'm not sure why this issue must be raised over and over.

> requirement to only transport well-formed HTML4 content, right?

Seems like overspecification to me. What's the benefit of going into 
detail here?

> general, I find RFC3339 much easier to read:

Noted.

> Is it intentional that the example is inconsistently indented?

Noted. A shorter namespace would help.

> ...speaks about namespace prefixe*s* being defined; but then only 

noted.

> s/namespace IRI/namespace URI/ (or "namespace name")

namespace URI, I think.

> considered "foreign "markup".

noted.

> "See the security sections of RFC 2854 and HTML 4.01 for guidance."

Will do.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Mar 2005 19:58:32 +0100

Robert Sayre wrote:
>> This has been mentioned before...: as far as I can tell, it's far 
>> easier for recipients to process "xhtml" compared to "html" (no 
>> tag-soup parser needed), thus *any* kind of change that encourages 
>> "xhtml" would be appreciated.
> 
> 

Because I feel it's important. There will be many clients that won't 
include a tag-soup parser, and markup sent as "html" will thus be lost. 
So *if* a producer has a choice of using "html" or "xhtml", I think 
"xhtml" is preferrable, and the spec should say so.

> Seems like overspecification to me. What's the benefit of going into 

I'd like to understand whether the spec indeed allows tag-soup, or if it 
actually requires valid HTML (which it seems to do right now). Thus, if 
people think that they can dump "arbitrary" HTML (such as user-entered) 
into type="html" elements, they are wrong as far as the spec currently 
states.

> ...

Best regards and thanks for the feedback,

Julian

---

From: Tim Bray <[email-masked]>
Date: Sun, 20 Mar 2005 11:44:30 -0800

On Mar 20, 2005, at 10:58 AM, Julian Reschke wrote:

> include a tag-soup parser, and markup sent as "html" will thus be 
> lost. So *if* a producer has a choice of using "html" or "xhtml", I 
> think "xhtml" is preferrable, and the spec should say so.

<co-chair-mode>I happen to agree with your position, but I can't in 
good conscience declare even rough consensus in our favor.  Leave it 
the way it is.</co-chair-mode>

> I'd like to understand whether the spec indeed allows tag-soup, or if 
> it actually requires valid HTML (which it seems to do right now). 
> Thus, if people think that they can dump "arbitrary" HTML (such as 
> user-entered) into type="html" elements, they are wrong as far as the 
> spec currently states.

Good point.  My impression is that we do currently have SHOULD-level 
mandate to serve valid HTML; recognizing that most real-world 
implementors do make a best-effort with tag soup.  Anyone who thinks 
that the language needs improving should suggest improvements. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Sun, 20 Mar 2005 16:44:59 -0500

> string "Less: <", where the less sign displays emphasized when possible..

Including that character is a smart idea, but I don't like the text 
itself. Mark and I will try to think of something, but suggestions are 
welcome.

> with "text/" or ends with "+xml"''?

This section needs to be reworked. It doesn't know what it wants to be. 
It mixes guidelines for producers with a processing model for clients.

> Update -06: I think it would be good if all W3C references came with URLs.

Agree. I grabbed the bibliography from resource.org, which doesn't 
include URLs for W3C specs. I figured there might be a reason for that.

> intra-document references.

But that's so boring! OK, ok, I'll do it.

> it easier to actually locate the definition.

Agree. Will fix for -07.

> to be section 3.4.1 (addr-spec production).

Agree. Will fix for -07.

> definition normatively (for instance, RFC2234).

Agree. Will fix for -07.

> Put the section reference into brackets.

Agree. Will fix for -07.

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Sun, 20 Mar 2005 14:17:48 -0800

--On March 20, 2005 11:44:30 AM -0800 Tim Bray <[email-masked]> wrote:
>
> Good point.  My impression is that we do currently have SHOULD-level mandate to 
> serve valid HTML; recognizing that most real-world implementors do make a best-effort
> with tag soup.  Anyone who thinks that the language needs improving should suggest
> improvements. 

I support a SHOULD on that. The Robustness Principle would suggest exactly
that. Consumers of Atom may make an attempt to parse arbitrary HTML-like
content, but producers should make the effort to serve clean HTML.

That free-range HTML is nasty stuff. In the past week, we had two customers
freely mixing slash and backslash in their URL paths. Sigh.

wunder
--
Walter Underwood
Principal Architect, Verity