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

[Julian Reschke <julian.reschke@xxxxxx>]

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

That's true, but I really don't think it's sufficient.

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

Well, I think it's now very misleading.

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

<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.4>:

"The 4xx class of status code is intended for cases in which the client 
seems to have erred. Except when responding to a HEAD request, the 
server SHOULD include an entity containing an explanation of the error 
situation, and whether it is a temporary or permanent condition. These 
status codes are applicable to any request method. User agents SHOULD 
display any included entity to the user."

So it's recommended, but not required. I'd prefer not to break a SHOULD 
level HTTP requirement, though :-)

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

Well, we could *say* what character is meant (using the UNICODE name).

> ...

Thanks for the other changes and best regards,

Julian