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

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


On 5/17/07, Julian Reschke <julian.reschke@xxxxxx> 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.


Fixed.


Section 3., para. 3:
OLD:

    o  IRI - An Internationalized Resource Identifier as defined in
       [RFC3987].  Before an IRI found in a document is used by HTTP, the
       IRI is first converted to a URI.  See Section 4.1.

NEW:

    o  IRI - An Internationalized Resource Identifier as defined in
       [RFC3987].  Before an IRI found in a document can used in an HTTP
       request, it must first converted to a URI.  See Section 4.1.

JRE: "used by HTTP" doesn't sound right.


Old ground we went over and over. wont fix.


Section 3., para. 4:
OLD:

    o  Resource - A network-accessible data object or service identified
       by an IRI, as defined in [RFC2616].  See
       [W3C.REC-webarch-20041215] for further discussion on Resources.

NEW:

    o  Resource - A network-accessible data object or service identified
       by an URI, as defined in [RFC2616].  See
       [W3C.REC-webarch-20041215] for further discussion on Resources.

JRE: RFC2616 defines resources being defined by HTTL URL (URI).


We have text in other places on the relationship between
IRIs and URIs. wont fix.


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


See Paul's message. wont fix.


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?



From Section 4.4:


"""Similarly while some HTTP status codes are
   mentioned explicitly, clients ought to be
   prepared to handle any status code from a server.
"""



Section 8.3.4., para. 2:
OLD:

    The app:accept element is similar to the HTTP Accept request-header
    [RFC2616].  Media type parameters are allowed within app:accept, but
    app:accept has no notion of preference - "accept-params" or "q"
    arguments, as specified in Section 14.1 of [RFC2616] are not
    significant.

NEW:

    The app:accept element is similar to the HTTP Accept request-header
    [RFC2616].  Media type parameters are allowed within app:accept, but
    app:accept has no notion of preference - "accept-params" or "q"
    arguments, as specified in Section 14.1 of [RFC2616] are not
    significant.

JRE: it's now less similar to the Accept header than it used to. Maybe
we need to rephrase this.


wont fix.


Section 9.5.1., para. 5:
OLD:

    The server signals a successful creation with a status code of 201,
    and returns an ETag header in the response.  Because in this case the
    server returned a Content-Location and Location header with the same
    value, the returned Entry representation can be understood to be
    complete (see Section 9.2) and thus the ETag entity value can be also
    be used.

NEW:

    The server signals a successful creation with a status code of 201,
    and returns an ETag header in the response.  Because in this case the
    server returned a Content-Location and Location header with the same
    value, the returned Entry representation can be understood to be
    complete (see Section 9.2) and thus the ETag entity value can be also
    be used for subsequent operations.


Already fixed in response to a message from Nikunj.


Section 9.5.1., para. 16:
OLD:

    The server however has since received a more recent copy than the
    client's, and responds with a status code of 412 (Precondition
    Failed).
        HTTP/1.1 412 Precondition Failed
        Date: Sat, 24 Feb 2007 16:34:11 GMT

NEW:

    The server however has since received a more recent copy than the
    client's, and responds with a status code of 412 (Precondition
    Failed).

        HTTP/1.1 412 Precondition Failed
        Date: Sat, 24 Feb 2007 16:34:11 GMT

JRE: whitespace. Also: shouldn't that contain a response body?


Fixed. And no, it doesn't need a response body.


Section 9.6.1., para. 13:
OLD:

         HTTP/1.1 200 Ok
         Date: Fri, 8 Oct 2006 17:17:11 GMT
         Content-Length: nnn

NEW:

         HTTP/1.1 200 Ok
         Date: Fri, 8 Oct 2006 17:17:11 GMT


Fixed.


Section 9.7.2., para. 4:
OLD:

     See Section 9.2.1 for an example of the Slug: header applied to the
     creation of an Entry Resource.

JRE: can we please spell out what the example slug stands for?


I would love to, but unless something has changed, we
are saddled with an ASCII only document format. cant fix.


Section 12.1., para. 1:
OLD:

    This document defines a new "type" parameter for use with the
    "application/atom+xml" media type:

JRE: say that this uses a RFC4234-style ABNF.


Fixed, by removing the ABNF and adding some prose
that said the same thing.



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


See Paul's message. wont fix.


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.


See Paul's message. wont fix.

  Thanks,
  -joe

--
Joe Gregorio        http://bitworking.org