... is now in the hands of the IESG...
===
Carl-Uno
-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
Sent: Wednesday, September 22, 1999 5:41 PM
To: IETF-IPP
Subject: IPP> FW: Last Call: Upgrading to TLS Within HTTP/1.1 to
Proposed Stan dard
FYI,
The document that describes how to invoke TLS over HTTP is not in the hands
of the IESG for ratification as a standards track document. Maybe this is
why the IESG has not yet let the IPP/1.1 docs through :-), you can always be
optimistic!
Carl-Uno
-----Original Message-----
From: Scott Lawrence [mailto:lawrence@agranat.com]
Sent: Wednesday, September 22, 1999 10:24 AM
To: IETF Transport Layer Security WG; iesg@ietf.org; Harald T.
Alvestrand
Cc: Rohit Khare; Http-Wg@Hplb. Hpl. Hp. Com
Subject: 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: iesg@ietf.org, IETF-Announce:;
> >From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
> >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 <lawrence@agranat.com> Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/