Re: HTTP Batch Request Draft

Bjoern,

Thank you for the detailed comments. As you have pointed out, much of 
the prose around the technical details is definitely lacking. As an 
initial draft, my intent was mainly to get the basic mechanism down and 
to fix up the prose in subsequent iterations of the document.

Bjoern Hoehrmann wrote:
> * 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).
>   
Ok, so I had to glance back at the definitions in RFC2616 and yes, 
message/http would appear to be the correct option in this case. I 
managed to get the definitions mixed up in my head (not a difficult task 
to say the least)
> 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.
>
>   
Noted. I already had such an edit planned for a future iteration.
> 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.
>
>   
Noted.
> 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").
>
>   
Noted.
> 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.
>
>   
Noted.
> 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.
>
>   
Good point. I will add that in. Basically, if a batch response does not 
contain a response to an individual batched request, the client should 
treat it no differently than if the server failed to respond had that 
batched request been sent by itself. The result of the request would be 
indeterminate.  If the batch response includes parts that do not 
correlate to parts in the batch request, then the client should ignore 
those parts.
> 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.
>
>   
Noted.
> 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?)
>
>   
Noted. These are precisely the kinds of technical details I am hoping to 
flesh out in subsequent iterations of the draft.
> 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...
>
>   
Noted.
> I do not think the draft should require that responses appear in the
> order of the requests.
>   
I've gone back and forth on this one and settled on the current 
"SHOULD". I am definitely not opposed to relaxing that tho. 
Realistically, a server will order the responses based on whatever 
mechanism it determines appropriate for processing the requests.

- James

Received on Monday, 8 June 2009 22:00:06 UTC