Skip to main content

Shepherd writeup
draft-ietf-regext-unhandled-namespaces

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