Subject: updated issues list for draft 07

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Apr 2005 21:44:57 +0200

Hi,

I just updated my issues list based on the current draft (that is, I 
didn't yet have time to scan for potential new issues). Most of the 
issues are editorial, but two of them IMHO really need to be addressed 
before the draft can be submitted (05-C05 and 05-E12).

Also, the embedded RNC grammar now works for me with the standard Jing 
validator from James Clark's web site. Thanks!

Best regards, Julian

--

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

"...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 :-)

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.

Update -07: I acknowledge that the WG is unable/unwilling to look at 
this topic again after att the discussions we had about it earlier in. 
I'll leave it here inside my issues list anyway so that my disagreement 
is at least recorded :-)

---

From: Robert Sayre <[email-masked]>
Date: Sat, 16 Apr 2005 14:49:21 -0400

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

Yes. In 4.1.3.3, you're supposed to apply them in order. Is that what 
you find confusing?

> attribute? 

I don't know. We should be able to strike them, right?

> Maybe it's not a SHOULD requirement after all?

In particular, that's a should against text/plain and text/html in @src.

Robert Sayre

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 16 Apr 2005 21:52:56 +0200

Julian Reschke wrote:
>> - is it intentional that 4.1.3.3 says ``If the value of "type" ends
>>  with "+xml" or "/xml"'',

This means the element content is some kind of XML: text/xml,
application/xml and any "+xml" type.
However, it excludes {text,application}/xml-external-parsed-entity.

Maybe the wording should be « If the value of "type" is a MIME media
type whose subtype begins with "xml" or ends with "+xml" »

>> while 4.1.3.2 used ``If the value of type begins with "text/" or 
>> ends with "+xml"''?

This means the element content is some kind of "text- or xml-based content":
text/plain, text/xml and any "+xml" type (image/svg+xml,
application/xhtml+xml, etc.).
However it excludes application/xml, as well as
application/xml-external-parsed-entity.

Maybe the wording should be « If the value of type is a MIME media type
whose type is "text" or whose subtype begins with "xml" or ends with
"+xml" ».
Although it depends what's the wanted meaning of the statement: should 
XML-based contents be provided inline when they are some kind of "human 
readable text content" (falls in the text/xml "group" as defined in 
[RFC3023], section 3. XML Media Types), or when they are "text-based" 
and can therefor be included without further "encoding" (other than 
"charset recoding" when necessary), which also includes "computer-only 
content" such as MathML, SVG, CSV, etc. ?

Moreover, the SHOULD in this section might be too strong: if you include
XML content, you loose DTD (thus validity) and, more important, entity
definitions (such as &nbsp; and others).

Please note that in the two previous wording proposals, « subtype begins
with "xml" » might be restricted to « subtype is "xml" or
"xml-external-parsed-entity" ».

> Yes. In 4.1.3.3, you're supposed to apply them in order. Is that what

I don't think Julian talked about it but, yes it's quite confusing...

Julian Reschke wrote:
>> - 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?

Because in 4.1.3.2 it was a SHOULD, not a MUST, so XML content MAY be
provided "outline".

[RFC3023] http://www.ietf.org/rfc/rfc3023.txt

-- 
Thomas Broyer

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Apr 2005 18:37:58 +0200

Robert Sayre wrote:
>> with "+xml" or "/xml"'', while 4.1.3.2 used ``If the value of type 
>> begins with "text/" or ends with "+xml"''?
> 
> 

Actually, this is what I didn't notice. My fault.

>> 4.1.3.3. point 4, make statements about situations where it comes with 
>> @src attribute? 
> 
> 

Yes. Either it's a SHOULD level requirement that the content is in-line 
(in which case we shouldn't say anything about the other case), or IMHO 
it's not a SHOULD after all.

> In particular, that's a should against text/plain and text/html in @src.

Hm, I didn't get that. Right now it says 
(<http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.2>):

"If the value of type begins with "text/" or ends with "+xml", the 
content SHOULD be local; that is to say, no "src" attribute should be 
provided."

Are you saying that the requirements are different for (i) "text/" and 
(ii) for "/...+xml"?

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Mon, 18 Apr 2005 13:29:30 -0400

> it's not a SHOULD after all.

Fair enough.

> Are you saying that the requirements are different for (i) "text/" and 

Yes, because it isn't base64 or escaped, you can't put text/plain or 
text/html inline. So, you have to use @src, but you SHOULD NOT. The fact 
that every MIME type under the sun can't be accomodated isn't a serious 
flaw, though.

Robert Sayre