Re: [apps-discuss] APPSDIR review of draft-ietf-mile-rfc6046-bis-03

[Brian Trammell <[e-mail]>]

Hi, Julian,

Thank you for the detailed review; answers to questions which can be simply addressed in the document will be incorporated into the next revision. 

I'm copying comments on specific points for discussion to mile and apps-area, inline.

Best regards,

Brian

On Dec 11, 2011, at 8:14 PM, Julian Reschke wrote:

> What I'm missing here are a few things that would probably make it easier to understand what's actually required:
> 
> 1) Does a RID endpoint need to implement all REQUIRED HTTP/1.1 features? For instance, does it need to understand Expect: 100-continue, and does it have to support GET and HEAD on "/"? Are there requirements for request URIs other than "/"?

As (1) the probable implementation path in most cases is to build a RID implementation atop an existing web server and (2) there is probably more to lose than to gain in attempting to define a coherent subset of the REQUIRED features, I would tend to think that all HTTP/1.1 REQUIRED features are REQUIRED for RID transport over HTTP/1.1. This goes for proper handling of potentially cached content and "proxy-friendliness", as well as handling of 100 Continue... (Is there a list of REQUIRED features in 1.1? seems like this would be a useful thing to have in a BCP56-bis...)

On specific points:

I presume that any access to non / URIs should return 404, since those resources in essence do not exist on the server; this should be noted.

The question as to what to do in case of GET / and HEAD / should be addressed, and I'm not sure what the right thing to do here is. Logically, this should be the same as what happens as POST with an empty body, which is also presently undefined. Allowing a text/html reply explaining that this is a RID system and what that is might be the most "user-friendly" solution (for people who aren't actually users of the system) but having the semantics and the media type of the reply depend on the method seems a little wrong, too. I presume a 405 Method Not Allowed violates a MUST in 2616? In any case, it would probably be difficult to implement based on many/most existing web servers.

> Nits:
> 
>   RID systems SHOULD NOT use TCP port 443 (the standard port for HTTP
>   over TLS/SSL) for RID messages; this avoids posting RID messages to
>   web servers that may not handle RID messages correctly.
> 
> Actually, it does not, because a web server may run on the RID port (4590) as well. If there's a security concern with the protocol with respect to generic web servers, it should be pointed out (and potentially fixed).

There's no security problem (at least, accidental connection to the wrong server should be prevented by proper verification of certificates). The intention here is simply that a RID System be easily distinguishable from a "normal" web server.