Re: [TLS] Confirming Consensus: Negotiating upper layer protocols

Though I wasn't in Atlanta, taking on this work seems to make plenty of sense.

Also, agreed on using a more standard TLS encoding - that also makes plenty of sense.

Thanks!

Stephan

-----Original Message-----
From: Andrei Popov [mailto:Andrei.Popov@microsoft.com] 
Sent: Friday, February 08, 2013 12:34 PM
To: Peter Gutmann; tls@ietf.org
Cc: Stephan Friedl (sfriedl)
Subject: RE: [TLS] Confirming Consensus: Negotiating upper layer protocols

I agree that the current language is unclear; Peter's suggestion looks good to me.

Thanks,

Andrei

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann
Sent: Friday, February 8, 2013 2:51 AM
To: tls@ietf.org
Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols

Eric Rescorla <ekr@rtfm.com> writes:

>WG members, please provide any comments on whether we should take this 
>work on by February 21. Additionally, if you wish to propose an 
>alternative, it would be nice if you could do so soon or at least 
>provide an indication of interest.

A comment on both of these proposals, to encode their protocols they use an ad-hoc, non-TLS-style encoding whose form is rather unclear:

  Protocols are named by IANA registered, opaque, non-empty byte strings and
  the list of protocols is serialized as a concatenation of 8-bit, length
  prefixed byte strings.

Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, or neither?  What's wrong with:

  opaque ProtocolName<1..2^16-1>;

  struct {
      ProtocolName protocol_name_list<1..2^16-1>
      } ProtocolNameList;

which fits the way everything else is done in TLS?

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls