1. Agree 2. Option 1
Attribute parsing should be easier with this option 1 - Length can always serve as a pointer to the next attribute, with explicit namespace ID. With option 2, attribute delimiters are only within NS-Specific, and Length points to the Namespace, if any. That makes two code paths, one for parsing NSID delimiters, and one for parsing attributes. However, the chances that I'll ever actually implement this are incredibly slim, so my opinion shouldn't be considered with much weight. Greetings, Stefan > 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More > specifically the usage of a channel binding specific TLV, the support of > multiple name spaces, and that the server indicates to the client what > attributes were validated. > > 2. Two encoding method where described in IETF-80 in the following > presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf. Do you prefer > encoding option 1, where attributes are encoded individually or option 2 > where attributes in the same namespace are grouped together. > > Cheers, > > Joe > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
