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

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?

To me, that feels more like a "protocol based upon HTTP" as defined in Section 2, which implies that in a perfect world, IPP would define its own ALPN identifier. 

Does that make sense (not saying it needs to happen now, as this is a forward-looking document)?

According to the current section 2, it'd also need to use its own IANA registries, but perhaps that should be clarified to say that if new, protocol-specific values are needed, separate registries must be used (since AFAICT IPP doesn't add any methods, headers or status codes).

> - Section 3.3: Concerning the list of things the RPC mechanism "fails to realize":
>  a. Caching of the results of an RPC sequence isn't possible (HTTP POST semantics), but support files *can* be cached - in the case of IPP that means localization files, icons, ICC profiles, and other printer resources, as well as status/information pages (which are viewable in a regular browser) whose URLs are discovered via an initial HTTP POST request.

Yes, but that's not pure RPC; sometimes it's entirely appropriate to use POST. Will try to clarify.

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

>  c. Redirection similarly is possible, although there have been historical interop/confusion issues with POST and 3xx statuses (and what to do) that aren't limited to this usage.

Ack. I think this is really separate; it's about client capabilities / expectations (which might deserve a new section).

>  d. At least with IPP, we have an explicit (IANA-managed) extension and versioning process for IPP messages (application/ipp message body). This can definitely be an issue if not planned for, however, so it should be mentioned as a best practice when defining the message body formats.

This was referring more to the versioning of resources, etc. that a rich set of URIs gives you. Will try to clarify.

> - Section 4.4: Editorial issue in third paragraph, change "has" to "have", "While historically some applications (e.g., [RFC4791]) HAVE defined ..."
> 
> - Section 4.4 and 4.5: Maybe change passive "When it is believed that" to "When authors believe that"?
> 
> - Section 4.5: Maybe change anthropomorphic "Status code's primary function" to "The primary function of status codes"?
> 
> - Section 4.7: Maybe also add a CBOR reference?

Thanks, will fix in the next round.

> - Section 4.8: This is a best-practice document so I'm not sure it should/can make normative requirements or prohibitions of its own.  Personally I would like to see this worded as recommendations with references to the corresponding sections in RFC 7616 and 7617 - clearly Basic over 'http' is not secure (and RFC 7617 says as much) so I think a MUST NOT is appropriate and consistent, but Digest over 'http' does offer some cryptographic protections so an outright ban is not warranted - better to simply say Basic MUST NOT be used with the 'http' URL scheme and all authentication schemes SHOULD be used with the 'https' URL scheme?

The question about requirements text is a good one -- this has been in the back of my mind, and I'm open to finding ways to reword things.

See <https://github.com/httpwg/http-extensions/issues/457> for a discussion of Digest. I'd forgotten that 7616 added algorithm agility, so I've reopened that.

> - Sections 4.9 and 4.10: I don't know whether we can make this more visible/explicit, but these are (IMHO) the biggest drawbacks and challenges of a HTTP-based Application.

Agreed; will look into it (and I'd love to expand those, if anyone has suggestions).

> - Section 6: Section 4.10 should be referenced here as well.

Ack.

> Overall I think the new document is a big improvement over RFC 3205!

Thanks!

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

Received on Wednesday, 14 February 2018 01:41:12 UTC