[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More comments on pre-draft (as of 2007-05-17)


At 2:53 PM +0200 5/17/07, Julian Reschke wrote:

INTRODUCTION, para. 14:
OLD:

   The Atom Publishing Protocol (APP) is an application-level protocol
   for publishing and editing Web resources.  The protocol is based on
   HTTP transfer of Atom-formatted representations.  The Atom format is
   documented in the Atom Syndication Format [RFC4287].

NEW:

   The Atom Publishing Protocol (APP) is an application-level protocol
   for publishing and editing Web resources.  The protocol is based on
   HTTP transfer of Atom-formatted representations.  The Atom format is
   documented in the Atom Syndication Format.

JRE: no references in the abstract, please.
+1. The RFC Editor has been inconsistent about this, but "no refs in abstract" seems to be the current flavor. 


Section 3., para. 5:
OLD:

   o  relation (or "relation of") - Refers to the "rel" attribute value
      of an atom:link element.

NEW:

   o  relation (or "relation of") - Refers to the "rel" attribute value
      of an atom:link element (see [RFC4287], Section 4.2.7).
JRE: be more specific when referencing other docs (that applies to many other places as well...).
If the editors can do this, that's great, but it is not a show-stopper. (Same response for the similar proposals her.) 


Section 5.4.2., para. 3:
OLD:

   2.  If the deletion is successful the server responds with a status
       code of 200.
JRE: are we sufficiently clear that this may be another 2xx status, such as 204, as well?
To me, "200" means "200", not "2xx". I'm not sure what we want, but we don't want to mix those up. 


Section 9.1., para. 3:
OLD:

   A Member Entry SHOULD contain such an atom:link element with a link
   relation of "edit", which indicates the Member URI.

NEW:

   A Member Entry SHOULD contain such an atom:link element with a link
   relation of "edit", which indicates the Member URI.

JRE: see above.


These two look the same to me...


Section 15.7., para. 3:
OLD:

    Additional information about XHTML and HTML content safety can be
    found in Section 8.1 of [RFC4287]
JRE: didn't we discuss at some point of time what we need to warn against the "million laughs attack"? Can't see anything here....
We do not need such warning, although it would be fine to have. The warning is not related to APP itself, and is just one of many similar potential "have bounds in your XML processing" warnings. 


Section 16.1., para. 11:
JRE: I think most notes to the RFC Editor can go if we just always say "This Specification", and insert the IESG as change controller. 

Don't bother with this one; the RFC Editor does this anyway.