Re: Comments on draft-ietf-httpbis-bcp56bis-01

On 15 Feb 2018, at 1:42 am, Michael Sweet <msweet@apple.com> wrote:
> 
> Mark,
> 
>> On Feb 13, 2018, at 8:40 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> Hi Michael,
>> 
>> Thanks very much for the comments. Responses below.
>> 
>>> On 14 Feb 2018, at 4:28 am, Michael Sweet <msweet@apple.com> wrote:
>>> 
>>> All,
>>> 
>>> I've read through this first draft and have the following feedback (seen through the lens of IPP, which has successfully used HTTP as its substrate for 20+ years now...):
>> 
>> Understood. IPP is interesting, in that AFAICT it defines its own URI schemes and default ports, but *appears* to reuse the HTTP ALPN identifiers and the POST method, correct?
> 
> Correct, but the 'ipp' and 'ipps' URI schemes explicitly define how those URIs are converted to 'http' and 'https' URIs for use over the HTTP/HTTPS transport - as I recall that particular bit was specifically requested by the old HTTP and URI WGs so that it was clear that IPP explicitly used HTTP semantics at the "transport" level.

Ah, right - completely forgot about that.

I suspect you wouldn't get such a request if you asked now, and indeed it'd probably be discouraged; see:
  https://www.w3.org/TR/webarch/#URI-scheme


>>> b. Authentication and access control is explicitly supported by HTTP POST, and has been effectively used with IPP since day one. Not an issue, and in fact tunneling through HTTP has been an asset.
>> 
>> I suppose the intent here was *granularity* of access control. Will see if I can clarify (but point taken).
> 
> Even for granularity - non-idempotent methods like POST and PUT allow the server to examine the message body of the request before responding.  And in the case of IPP we recommend the use of the HTTP Expect header in requests so that an IPP client can avoid sending gigabytes of print data until the server has given its go-ahead.
> 
> (There are some practical interoperability concerns with Expect, which we *do* talk about in our implementor guides...)

That's a good point; we should probably talk about relying on Expect/Continue, pipelining, and other "special" HTTP features.

Thanks!

--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 15 February 2018 04:16:14 UTC