Shepherd writeup
rfc9038-08

Shepherd writeup
draft-ietf-regext-unhandled-namespaces-06

Technical Summary
===

This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730, occasioned by the handling of certain poll messages.

Working Group Summary
===

draft-ietf-regext-unhandled-namespaces-06 is on standards track as an Applicability Statement, having originally been considered as a BCP.  It specifies a way for a server to return data to a client when the server knows that the data's namespace was not specified as being supported by the client (via the client's negotiated login services). The server accomplishes this by embedding the unhandled-namespace information into <extValue> elements in its responses. Because the server's responses conform to RFC 5730, these responses will pass any client's strict XML parsing while also delivering the unhandled-namespace data for the client to consume (or ignore) as it sees fit.

There remains a difference of opinion on whether the draft will incur "interoperability problems" with respect to the way RFC5730 describes <value> and <extValue> elements. Specifically, the concern is whether clients will neglect to capture the <extValue> data returned in an unhandled-namespaces response due to those clients receiving a "success" response code when they had expected to look at the <extValue> only in cases of an "error" response code. To address these concerns, the draft now includes an Implementation Considerations section with guidance for both clients and servers.

Document Quality
===

This document has been discussed on the regext mailing list, and its authors have repeatedly edited the document to address concerns. The document now includes an "Implementation Considerations" section to provide specific guidance to both clients and servers to reduce any  operational impacts of the processes described in the draft.


Personnel
===

Document shepherd is David Smith: dsmith@verisign.com
Area Director is Barry Leiba: barryleiba@computer.org

Shepherd Comments
===

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.

As mentioned in the "Working Group Summary," above, the "Implementation Considerations" portion of the document points to important information for servers and clients. I don't know whether the draft should somehow place more emphasis on this section, or how it would do so, but the mailing-list participants seem to be fine with its inclusion, placement, and level of emphasis. 

The move from BCP to standards track resulted from the September 16, 2020, mailing-list discussion of such. There, Scott Hollenbeck stated that: 

  "If we as a community can't agree that the documents describe best current practices, then it might not be appropriate for them to be published as BCPs. I'd feel more comfortable with publication on the standards track as technical specifications ("A Technical Specification is any description of a protocol, service, procedure, convention, or format") as described in Section 3.1 of RFC 2026."

This statement elicited a positive response.

The authors have confirmed that they've followed BCP78 and BCP79. No IPR disclosures have been submitted for this document.

All normative and informative references have been verified.

As document shepherd I believe this document is ready for publication.
Back