Subject: Re: Last Call: Upgrading to TLS Within HTTP/1.1 to Proposed Standard

From: EKR <[email-masked]>
Date: Wed, 13 Oct 1999 04:32:26 +0100 (BST)

Jeffrey Schiller <[email-masked]> writes:
> [3] definitely appears to be normative. Can we get Eric's Document 
> advanced (This question is to the working group)?
I've received last call comments from Bodo Moeller with new
wording for one section. There have been no technical 
changes.

I've just responded to Bodo's message. Unless there are any
objections, I believe we can move the document forward
with the indicated trivial changes. (I.e. I'll submit a new
I-D with them.)

-Ekr
-- 
[Eric Rescorla                                   [email-masked]]
          PureTLS - free SSLv3/TLS software for Java
                http://www.rtfm.com/puretls/

---

From: Jeffrey Schiller <[email-masked]>
Date: Wed, 13 Oct 1999 03:54:57 +0100 (BST)

I didn't realize you were waiting for me to approve. Please do make 
the necessary changes and submit a new document.

				-Jeff

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 9/22/99, 5:23:55 PM, "Scott Lawrence" <[email-masked]> wrote 
regarding Re: Last Call: Upgrading to TLS Within HTTP/1.1 to Proposed 
Standard:

> > >The IESG has received a request from the Transport Layer Security
> > >Working Group to consider Upgrading to TLS Within HTTP/1.1
> > ><draft-ietf-tls-http-upgrade-02.txt> as a Proposed Standard.

> > >To: [email-masked], IETF-Announce:;
> > >From: Harald Tveit Alvestrand <[email-masked]>
> > >Subject: Re: Last Call: Upgrading to TLS Within HTTP/1.1 to Proposed
> > >   Standard
> [...]
> >IANA considerations section for upgrade tokens is not thought 
through.
> >At the least, the registrant should be allowed to change the contact
> details
> >for a registration, so the statement
> >
> >  > 1. The registration for a given token MUST NOT be changed once
> registered.
> >
> >is obviously not what's desired.
> >
> >I'd suggest the following rules:
> >
> >1. A token, once registered, stays registered forever.
> >2. The registration MUST name a responsible party for the 
registration.
> >3. The registration MUST name a point of contact.
> >4. The registration MAY name the documentation required for the 
token.
> >5. The responsible party MAY change the registration at any time. The
> >     IANA will keep a record of all such changes, and make them
> available
> >     upon request.
> >6. The responsible party for the first registration of a "product"
> token
> >     MUST approve later registrations of a "version" token together
> with that
> >     "product" token before they can be registered.
> >7. If absolutely required, the IESG MAY reassign the responsibility 
for
> >     a token. This will normally only be used in the case when a
> responsible
> >     party cannot be contacted.
> >
> >A lot more words, but I think it's more workable.

> An excellent formulation.  The authors will gratefully accept this as 
a
> friendly amendment if the IESG concurs.

> --
> Scott Lawrence           Director of R & D        
<[email-masked]>
> Agranat Systems, Inc.  Embedded Web Technology   
http://www.agranat.com/

> ---
> You are currently subscribed to ietf-tls as: [[email-masked]]
> To unsubscribe, forward this message to 
[email-masked]

---

From: Jeffrey Schiller <[email-masked]>
Date: Wed, 13 Oct 1999 04:09:39 +0100 (BST)

Looks like we have an additional problem. The IANA comments:

>draft-ietf-tls-http-upgrade-02.txt, and has the following comment 
with
>regards to the publication of this document.
>
>	In the "References" section, there are three works in progress:
>
>		[3] "HTTP over TLS"
>		[5] "WebDAV Advanced Collections Protocol"
>		[8] "Tunneling TCP based protocols throught Web proxy 
>                     servers"
>
>	Current status?  Are any of them normative?
>
>
>Joyce K. Reynolds
>IANA Liaison to the IESG

				-Jeff

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 13 Oct 1999 09:17:36 -0400

> From: Jeffrey Schiller [mailto:[email-masked]]
> Sent: Tuesday, October 12, 1999 23:10
> To: IETF Transport Layer Security WG
> Cc: Rohit Khare; Http-Wg@Hplb. Hpl. Hp. Com

[3] documents existing practice for https
[5] is noted because it defines an HTTP status code - we could remove it
from this document and let them add an entry to the registry we are
creating.
[8] is an expired draft, referenced only because it was the original
description - this document replaces it as far as standards track is
concerned.

---

From: John Stracke <[email-masked]>
Date: Wed, 13 Oct 1999 11:09:23 -0400

> from this document and let them add an entry to the registry we are

I looked at draft-ietf-tls-http-upgrade-02, and spotted one glitch: you
mention that WebDAV defines status codes 420-424, but you didn't mention
207.  Not a big deal, maybe, but worth adding if you're updating the doc
anyway.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"I lost an 7-foot boa constrictor once in our|
[email-masked]|house." --Gary Larson on his youth           |
\==============================================================/

---

From: Jeffrey Schiller <[email-masked]>
Date: Wed, 13 Oct 1999 20:27:57 +0100 (BST)

> [3] documents existing practice for https

However this is still a normative reference, meaning that you need to 
have this document to understand what is being discussed. That is why 
I suggested that Eric's document be reviewed by the WG and submitted 
as a Proposed Standard.

> description - this document replaces it as far as standards track is

These are not a problem.

				-Jeff