On Wed, Jul 28, 2021 at 4:24 PM Benjamin Kaduk via Datatracker < nore...@ietf.org> wrote:
> In the interest of letting the document move forward, I am balloting > Abstain > because the document still contains behavior that, while fully specified, > seems to require additional conditional behavior in client implementations > that results in unnecessary fragility of implementation. The responsible > AD and WG chairs should confirm that the WG does indeed have consensus to > have made this decision, but I have no other grounds to block the > document's > publication once that consensus is confirmed. > Can the chairs please respond to this point? I'd like to get something on the record before we move the document forward. Thanks, -MSK, ART AD Copying the point from my previous discuss ballot in order to provide > specifics > on the behavior that prompts my Abstain position: > > (2) There's also some text in Section 5.3 that I'd like to discuss briefly: > > The registry MUST NOT return any indication of whether the > authorization information is set or unset to the non-sponsoring > registrar by not returning the authorization information element in > the response. The registry MAY return an indication to the > sponsoring registrar that the authorization information is set by > using an empty authorization information value. The registry MAY > return an indication to the sponsoring registrar that the > authorization information is unset by not returning the authorization > information element. > > This seems to be assigning semantics to both absent-authinfo and > empty-authinfo in the <info> response, but is giving *different* semantics > to the response-to-sponsoring-registrar and > response-to-non-sponsoring-registrar cases. Is there precedent for > changing the semantics of the response based on the identity of the > client like this (not just changing the content of the response)? Can > we come up with a scheme that provides consistent semantics to all > clients, perhaps based on <domain:null> vs empty <domain:pw> for > unset/set, leaving "element is absent" for the deliberately ambiguous > case? >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
