Re: HTTP Batch Request Draft

* James M Snell wrote:
>FYI: http://www.ietf.org/internet-drafts/draft-snell-http-batch-00.txt
>
>This is an initial draft and comments/feedback are requested and 
>desired. Thank you,

It is not clear why you are using application/http; the main difference
to message/http is that you supposedly can specify many requests or re-
sponses (in practise that is difficult because you cannot properly de-
tect message boundaries without knowing requests and responses, but you
cannot specify them together), and your type pretty much assumes that
you have individual messages anyway (the draft refers to individual re-
quests throughout).

The introduction should note at least some of the limitations of pipe-
lining if there are a number of them. I would rephrase it wholesale so
it explains how it complements pipelined requests instead of merely
noting that it is not meant to replace it.

The RFC 2119 keywords should be in a separate section on terminology;
the introduction is meant to explain what the document is about, not
how to read it.

It might be better to refer to Internet media types as media types,
not content types (also beware confusing "content type", "content-
type" and "Content-Type").

I initially did not understand "Each part in the batch MUST share a
common Content-Type as specified by the Multipart/Batch content types
Type parameter"; later I realized what you want to say is that all
the individual parts must be of the type specified in the "type" pa-
rameter. Please rephrase that. It might be a good idea to merge this
with the section defining the parameter.

You should have a reference to the definition of the Content-ID header.

The use of "Server: example.org" is confusing, do not use strings that
look like domain names there.

You say how to handle parts that do not specify the expected Content-
type header, but do not say how to handle parts that fail to meet the
requirements for Content-ID and In-Reply-To. It is not clear to me that
In-Reply-To is the right header to use.

The type registration fails to meet requirements of RFC 4288. It is
also contradictory, type for example seems incorrectly defined as it
would seem that parameters are prohibited.

As you primarily intend it to use with HTTP, I am unsure if it is a
good idea to define a far more general type. Also, given the focus on
HTTP, you ought to say a few things about e.g. detecting message
boundaries (if a part is N bytes long but the Content-Length header or
chunks in the message lead to a length of M, what then?)

You should add a line of text to the Abstract per the I-D guidelines.
Good to know though that drafts with less than 3 lines are no longer
rejected...

I do not think the draft should require that responses appear in the
order of the requests.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 8 June 2009 21:40:34 UTC