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

Brian Trammell <> Mon, 12 December 2011 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71C7221F8AF4; Mon, 12 Dec 2011 08:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ptc3+W7fcc62; Mon, 12 Dec 2011 08:59:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8943C21F8AAF; Mon, 12 Dec 2011 08:59:28 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7ED3D9309; Mon, 12 Dec 2011 17:59:27 +0100 (MET)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id b9+JpEABrNbW; Mon, 12 Dec 2011 17:59:27 +0100 (MET)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by (Postfix) with ESMTPSA id 95D81D9305; Mon, 12 Dec 2011 17:59:27 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell <>
In-Reply-To: <>
Date: Mon, 12 Dec 2011 17:59:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Julian Reschke <>,
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Tue, 13 Dec 2011 08:02:30 -0800
Cc:, The IESG <>, IETF Apps Discuss <>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mile-rfc6046-bis-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Dec 2011 16:59:29 -0000

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,


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.