[ietf-provreg] EPP, data, actors, and access

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Oki all,

We have two distinct proposals for a specification of access, data, and
actors for EPP. External to EPP, but possibly relevant, is the existence
of WHOIS (954).

One approach scopes some meta-data to sessions, within a connectionist,
client-server model, with the server originating the meta-data. As a
matter of syntax, this approach is extensible as to semantics associated
with a session.

One approach scopes some meta-data to data only, with the client originating
the meta-data. The syntax for this approach is various, but two designs of
note are an element (in the degenerate case, an attribute only) for some or
all elements of data, and an element for each aggregation of data, e.g., the
contact object, with some mapping to some or all elements of data within the
aggregation.

It is possible that if both a session-scoped mechanism, and a data-scoped
mechanism are presented to a pair of EPP peers, neither being semantically
null, that the peers will not correctly and interoperably evaluate the
semantics of both mechanisms.

This is made more likely if the evaluation-spaces of the two mechanisms
are not identical, nor avail trivial forward and reverse mapping between
nominally equivalent mechanism-specific representations.

A design choice pioneered, at least within the PROVREG context, by one
contributor, is to add a binary toggle, or a set of enumerated values,
that allow some new semantic. As that contributor demonstrated, and as
a subsequent implementations have shown, it is possible to add payload
with a distinct syntactic form. See [1] for details.

I mention this to acknowledge that a WHOIS-specific optimization is a
possibility, that such a "hack" need not conform to the syntax of the
current protocol, and that as an implementation matter, it is tractible.
I add that such an optimization presents challenges for users who may
seek to modify the optimization, or to obtain transparently equivalent
transaction semantics, independent of EPP endpoint operator.

One statement associated with client-origination is that it is actually
registrant-origination. This presents two problems, the first theoretic,
as EPP is between registrars and registries. The working group chose to
create an interoperable protocol for data exchange between registrars and
registries. Some other working group may be formed, if an interoperable
protocol for data exchange between registrants and registrars is useful.

The second problem is user-interface specification. Is the value-space of
the new data binary? Is it an enumerated set?  Is it an enumerated set of
enumerated sets? Is it a tree with some branch ordering and evaluation
property? Isn't this a discussion of what boxes, knobs, and sliders exist
on a registrars registrant-facing data collection API? There are instances
of UI specification within the IETF, but that is not in the PROVREG charter.

I've written quite a bit over the past several months, critically, but
as intelligently as I can manage, on what is referred to as "the IESG
privacy proposal". I have no objective indication that any member of
the IESG has read anything I've contributed to the PROVREG list. That's
OK, this isn't some quest for emotional gratification. What puzzles me
is the utter lack of substantive contribution, whether responsive to
my writings, or those of anyone else, that moves beyond a gesture towards
a requirements statement.

Real requirements are intelligently discussed, unless they arise from
kings, presidents, and voting.

Real proposals are in the form of public drafts, eventually.

Eric

[1] draft-liu-epp-ustld-01.txt, expired. Author at liu@cis.umassd.edu.
A copy may exist in the PROVREG list mail archive.