Skip to main content

Extensible Provisioning Protocol (EPP) Unhandled Namespaces
draft-ietf-regext-unhandled-namespaces-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: David Smith <dsmith@verisign.com>, The IESG <iesg@ietf.org>, barryleiba@gmail.com, draft-ietf-regext-unhandled-namespaces@ietf.org, dsmith@verisign.com, regext-chairs@ietf.org, regext@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Extensible Provisioning Protocol (EPP) Unhandled Namespaces' to Proposed Standard (draft-ietf-regext-unhandled-namespaces-08.txt)

The IESG has approved the following document:
- 'Extensible Provisioning Protocol (EPP) Unhandled Namespaces'
  (draft-ietf-regext-unhandled-namespaces-08.txt) as Proposed Standard

This document is the product of the Registration Protocols Extensions Working
Group.

The IESG contact persons are Murray Kucherawy and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/


Ballot Text

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.  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
Area Director is Barry Leiba

RFC Editor Note