FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt

Hi folks,

We just posted an internet-draft updating the extensions RFC to deal with
the issue of which documents can define new extensions - the current RFC
allows only standards track RFCs while this draft allows any RFC based on
IETF consensus (which basically means IESG review).

I've summarized the detailed list of changes below.

Eric/Win ... How do you want to handle this? Given the minor nature of the
updates, can we proceed with working group last call on this (and the ECC in
TLS draft)?

Best regards. Simon 

Here's a summary of the changes:

- Assignment of ExtensionType values handed over to IANA. New values can be
assigned only via the IETF Consensus process. (This means that an RFC is
required and the RFC must have undergone IESG review.) This affects Section
2.3, Section 5, and Section 8.

- The text concerning handling of extensions during session resumption
requests has been clarified since the previous text was ambiguous, and it
would be bad to have to update the RFC again to deal with any RFCs that come
along and need clarity on this. This affects the last paragraph of Section
2.3 and the third paragraph of Section 3.

There are also a few minor editorial changes - updating references, author
addresses and the like.

> -----Original Message-----
> From: tls-bounces@lists.ietf.org 
> [mailto:tls-bounces@lists.ietf.org] On Behalf Of 
> Internet-Drafts@ietf.org
> Sent: Wednesday, December 29, 2004 3:43 PM
> To: i-d-announce@ietf.org
> Cc: ietf-tls@lists.certicom.com
> Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories. This draft is a work item of the 
> Transport Layer Security Working Group of the IETF.
> 
> 	Title		: Transport Layer Security (TLS) Extensions
> 	Author(s)	: S. Blake-Wilson, et al.
> 	Filename	: draft-ietf-tls-rfc3546bis-00.txt
> 	Pages		: 29
> 	Date		: 2004-12-29
> 	
> This document describes extensions that may be used to add
>    functionality to Transport Layer Security (TLS).  It provides both
>    generic extension mechanisms for the TLS handshake client 
> and server
>    hellos, and specific extensions using these generic mechanisms.
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc3546bis-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> i-d-announce-request@ietf.org with the word unsubscribe in 
> the body of the message.  
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-tls-rfc3546bis-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-tls-rfc3546bis-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls