No, we do not have the *requirement* to be standards-compliant.
However, I feel that browser-based clients are an important, low-
threshold, means to gain additional users. Therefore, we should not
make those clients inherently non-compliant, especially given the
attention we give them elsewhere (BoSH, WebSockets, …).
Also, I always find that it is nice to have some checkmarks. For
example, I think the XMPP (server) compliance tester has done an
excellent job at motivating server providers to achieve some more
checkmarks and thus raise the quality level. Therefore, I assume a few
more client authors could be motivated to become standards compliant,
if that were achievable.
Is RFC6120bis in the works? So changing the MUST to a SHOULD for SCRAN-
SHA-1-PLUS there would probably be best. Otherwise, a note in XEP-0412
at least stating the problem, or, as I suggested earlier, even right
out granting an exemption, would be great.
With a note, developers of browser-based clients could at least state
"compatible with XEP-0412 as far as a web-based client can be (XEP-
0412#footnoteX)".
-Marcel

On Fri, 2019-02-08 at 08:24 +0100, Florian Schmaus wrote:
> On 08.02.19 07:23, Marcel Waldvogel wrote:
> > I just became aware that XEP-0412/RFC 6120 mandate SCRAM-SHA-1-
> > PLUS. Theway I understand it, the required TLS Channel Binding for
> > the SASL -PLUSschemes is not possible from browser-based clients,
> > as there is no wayto get at the required low-level TLS information.
> > Would it be possible to grant an exemption to the -PLUS requirement
> > forbrowser-based clients? I.e., have a footnote behind "RFC
> > 6120"consisting of "The mandatory-to-implement requirement ofSCRAM-
> > SHA-1-PLUS is waved for clients operating in environments
> > whereaccess to TLS information is not possible, i.e. browsers"?
> 
> RFCs can be modified. But this is possibly a point for 6120bis
> (thepotential follow up RFC of RFC 6120).
> On the other hand, it is probably not a real world issue, as
> theecosystem will adopt (and has AFAIKT). The only consequence is
> that yoursoftware may not claim full standards compliance, but this
> is usuallyonly an issue if you want to sell the product and you have
> a managerwhich demands standards compliance
> - Florian
> _______________________________________________Standards mailing
> listInfo: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: [email protected]
> _______________________________________________

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to