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

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.

On a historical note, the original (experimental) IPP/1.0 definition used the 'http' URI scheme; one of the changes made for IPP/1.1 (and the march towards Internet Standard - still in progress...) was the definition of the 'ipp' URI scheme.  'ipps' came a few years later as confidentiality/security started getting taken more seriously, although it took us a while to finally get *that* URI scheme registered...

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

Not really - IPP doesn't exist in a vacuum - every shipping network printer has a HTTP server that provides the printer's administrative web interface and file resources (icons, ICC profiles, message catalogs, etc.) in addition to handling IPP requests.  An IPP Client doesn't just connect to the printer to send it IPP requests, it also grabs those file resources that are necessary to present UI.

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

But again, IPP's URI schemes are explicitly defined as mapping to HTTP:

    http://tools.ietf.org/html/rfc3510  IPP: IPP URL Scheme
    http://tools.ietf.org/html/rfc7472  IPP over HTTPS Transport Binding and 'ipps' URI Scheme

IPP *does* have its own registries for the elements in the application/ipp message format, but the transport is explicitly HTTP.

    http://www.iana.org/assignments/ipp-registrations/ipp-registrations.xml

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

Right, my point is that while the RPC messaging itself is not cacheable (just as any POST is not cacheable, per section 4.2.1 of RFC 7231 and sections 3 and 4.4 of RFC 7234), resources referenced by the Application RPC MAY be cacheable. It is important when designing such RPC to maximize the opportunities for caching by using HTTP GET/HEAD for accessing resources rather than defining "get file" RPCs (unless there is a compelling reason to do so...)

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

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

Agreed.  (and redirection tends to have security implications as well)

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

Right, I agree that MD5 is laughable, but SHA-256 is still reasonably safe (with a "proper" password)...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

Received on Wednesday, 14 February 2018 14:43:03 UTC