ietf
[Top] [All Lists]

Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

2012-06-10 12:39:34
Adding to what SM already wrote (and yes, I've reread the whole document):

On 1 Jun 2012, at 21:23, SM <sm(_at_)resistor(_dot_)net> wrote:

At 09:42 01-06-2012, IESG Secretary wrote:
The IESG has received a request from the TLS Working Group to reclassify RFC 
2818 (HTTP Over TLS) to Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action. Please send substantive comments to the ietf at 
ietf.org mailing lists by

Could the IESG please use ietf(_at_)ietf(_dot_)org instead of obfuscating the 
email address?  Some of us are lazy especially on Fridays.

Erratum #1077 has been classified as "Held for Document Update".  Will there 
ever be a document update?  Implementing this specification requires HTTP/1.1 
and TLS 1.0.  I suggest updating the reference to RFC 4346 at least and 
waiting for the updated HTTP specifications.


Yes, it would be worth doing that if the document is reopened.

St. Andre and Mr. Hodges authored a Proposed Standard called "Representation 
and Verification of Domain-Based Application Service Identity within Internet 
Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of 
Transport Layer Security (TLS)".  Quoting from Section 1.4:

 "the procedures described here can be referenced by future
  specifications, including updates to specifications for
  existing application protocols if the relevant technology
  communities agree to do so."

May I suggest taking the above into consideration and at least put some 
minimal effort into a 2818bis?


Not surprisingly I agree with you.

Also note that HTTPBis WG has folded the updated definition of https:// URI 
schemes (Section 2.4 of RFC 2818) into one of its documents. I think it would 
be good to make it clear to readers which document defines the URI scheme.

As far as reopening the document is concerned: I slightly prefer to do 
rfc2818bis although I understand that doing a -bis always takes longer than 
originally anticipated.