Patrick, We'll agree to disagree with the value and risk of draft-ietf-regext-unhandled-namespaces, since I can't think of a theoretical or real risk to existing clients with at least two independent implementations. Your objection can be included in the document shepherd writeup, but as noted before there is no consensus to make a change.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 10/25/20, 6:23 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: 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://secure-web.cisco.com/1JXSBPoG-78NoxpuH19NNm2nvZTdQOhccfcp1QWP5dIEoQ6ekz0xXZM5s-sjWAtHoyCWUf_2JEydMxz45_96qI1YCrzvVHqo_auUMjwRjm8-vzii5f9vyKuSHuvmM1k3cQ0yIXjkmvgHMVJvCVWmcpbbHGNx0ZiX0M2UoaJSC_KsQkylfiD2W2c6kKOzUDsOD0A0YpWshVU8cx2Vl5xPIwkFkeDUxrAEM1QqgxxgX8Kl-TSaiWE0mnRbAdMiJ2hnWnQNYliLaaS3GpmXxZ8naGmsuWA4vrGgPbftN8s8SJt0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
