In the end, I still say that 99.999% of implementors and deployers will look at that and say: “Am I doing HTTPS? I am, so I’m good!” and leave it at that. :)
I’m in favor of Kathleen’s approach where we give the minimum version and the BCP pointer for people who really care, and at least say “go do the right thing” to people who might otherwise ignore it. — Justin > On Apr 3, 2015, at 4:08 PM, Leif Johansson <[email protected]> wrote: > > > > >> 3 apr 2015 kl. 21:16 skrev John Bradley <[email protected]>: >> >> Yes it is good, though reading that BCP may scare off implementers who will >> just ignore it. > > Those people are gona ignore a bunch of other good advise too. Lets not chase > the rabbit down every hole. > >> >> We may still want to give the current advice of >= tls 1.2 at the point of >> publication see BCP xx for additional considerations. >> >> John B. >> >> >> Sent from my iPhone >> >>> On Apr 3, 2015, at 2:57 PM, Hannes Tschofenig <[email protected]> >>> wrote: >>> >>> I learned something new: we can reference a BCP (instead of an RFC) and >>> even if the RFC gets up-dated we will still have a stable reference. >>> (See Stephen's response to my question below). >>> >>> This is what we should do for our documents when we reference TLS in the >>> future. We would reference the yet-to-become BCP (currently UTA-TLS >>> document) and we essentially point to the recommended usage for TLS >>> (version, ciphersuite, everything). >>> >>> Isn't that great? >>> >>> -------------------------------------------------------- >>> >>>> On 02/04/15 19:09, Hannes Tschofenig wrote: >>>> Hi Stephen, >>>> >>>> if I understand it correctly, you are saying if we reference a BCP # >>>> (instead of the RFC) then a revised RFC will get the same BCP #. I have >>>> never heard about that and if that's indeed true that would be cool. I >>>> might also have misunderstood your idea though. >>> >>> Yep, that's it. XML2RFC makes it hard but you can do it, worst >>> case via an RFC editor note >>> >>> S. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
