On Thu, Oct 22, 2020, at 08:47, Gould, James wrote:
> I do need to clarify one
> thing, there was no specific changes needed on the client-side to
> support draft-ietf-regext-unhandled-namespaces other than ensuring that
> the draft-ietf-regext-unhandled-namespaces XML namespace is included in
> the login services.
There was no specific changes needed on the client-side... for YOUR client.
Great for you, but from that you can not draw a conclusion that your draft
creates no problem whatsoever.
Please take into account there are other clients out there, that may work
differently and do different assumptions.
Your draft changes the assumptions in RFC 5730. And hence may break existing
clients. By saying that there was no problem for one client is not a proof
that interoperability was not broken.
> Clients should be capable of parsing and marshaling the
> <extValue> element regardless of whether or not
> draft-ietf-regext-unhandled-namespaces is supported.
This is unrelated. You are changing the text from RFC 5730 that says
explicitly this content is client provided. You are now redefining what
is in RFC 5730 by saying "any content is fine here".
> The
> approach taken with draft-ietf-regext-unhandled-namespaces enables the
> information to be returned without the chance of breaking a validating
> client that doesn't support the service,
This is untrue, as you change the semantics of RFC 5730 at least twice
(content of extValue, and possibly having value/extValue with NON error codes)
Your draft *clearly* creates a _risk_ for any existing client starting to break
once a server enables this feature. Saying that one client works fine is
not a measure of interoperability risks when it is deployed.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
