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

I agree that this might create an interop problem ... And I don't think we
want to get into changes that break backwards compatibility here.

BTW ... Am I missing something ... Values up to 2^16 would mean that you
can now negotiate to allow longer packets rather than fragment to require
shorter packets, wouldn't it?

Best regards. Simon

> -----Original Message-----
> From: tls-bounces@lists.ietf.org
> [mailto:tls-bounces@lists.ietf.org] On Behalf Of EKR
> Sent: Monday, January 03, 2005 12:21 PM
> To: Nikos Mavrogiannopoulos
> Cc: tls@ietf.org
> Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt
>
>
> Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:
>
> > On Thursday 30 December 2004 17:34, Simon Blake-Wilson wrote:
> >> 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).
> > Since it is being updated I'd suggest to increase the
> number of valid
> > values
> > for MaxFragmentLength. I think values for up to 2^16 would be ok.
>
> That seems like it might create an interop problem, no?
>
> -Ekr
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
>

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

Attachment: smime.p7s