Hi Oleg, >I remember that some EAP-TLS/PEAP clients rejected not fragmented messages >without L bit set, probably due to their wrong interpretation of EAP-TLS >RFC. Would it worth to say something like "Implementation SHOULD accept >unfragmented messages with and without L bit set" in addition to copying >the sentence above from RFC 5281?
I added the following text to draft-ietf-emu-eap-tls13-04: "EAP-TLS fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant)." I don't know if anything more if needed, but if we add something I think it should be "MUST accept" rather than "SHOULD accept". The other alternative would be to instead write "Unfragmented messages MUST NOT have the L bit set and include the length of the message (though this information is redundant)." I think we need to choose one and ensure that implementations following draft-ietf-emu-eap-tls13 can talk to each other. Do anybody have any data on how many implementations out there set the L bit for unfragmented messages and how many implementations do not accept unfragmented messages with the L bit set? Cheers, John _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu