Comments on draft-ietf-httpbis-bcp56bis-01

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

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

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

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

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

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

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

Received on Tuesday, 13 February 2018 17:29:26 UTC