Re: Domain check in draft-obispo-epp-idn-00.txt

On Thu, Jan 05, 2012 at 02:00:06PM -0500, Michael Young wrote:

> Interesting thoughts - I'm really a big fan of avoiding multiple
> extensions that effectively do the same thing. I think we could
> benefit by having some more structure around how ICANN works/depends
> with IETF efforts. Right now it seems pretty reactive to industry
> needs versus maybe trying to anticipate needs.

ICANN doesn't actually control a very large number of the registries
it deals with, as any ccTLD manager will tell you at length if you
mistakenly phrase things as though perhaps ICANN has any influence of
any sort on them.  So it'd probably just cause heartburn to start by
thinking about how ICANN is involved.

Anyway, it seems to me that the basic problem with EPP extensions is
that everyone thinks everyone else's approach is wrong, because most
of the approaches are actually designed around an implicit underlying
data model.  Nobody ever wants to compromise on that, so you either
get extensions that are bloated pigs of optional elements, or else you
get a lot of extensions.  (The preposterous handling of name servers
as both references to host objects and as attributes of domain objects
in the original EPP documents is an example of this.  I understand why
it happened, and I have no criticism that the protocol ended up this
way; but if one wanted to design a clean data exchange protocol,
something this fundamental would not have two completely different
ways of handling the same sort of data.)

I think the problem is not only the number of extensions.  It seems to
me that if they were handled in a more co-ordinated way, that would be
good; but since they're not likely to be any time soon, then we need
to find another way.  The other way would be to fix client systems so
that pluggable extensions were considerably less clumsy to use.  The
main reasons I heard people complaining about extensions in the past
was because they needed to do significant development every time one
was encountered.  But in a well-designed system, that shouldn't be
true.  For a significant extension of additional data elements, one
has to do development anyway in order to make the data store
correspond to the new data.  For an extension that is really just
another, not-invented-here way of achieving the same registration
goal, a mapping of existing elements ought to be trivial.  In the
former case, then, some development is necessary anyway, and it's only
a poor client design that would make adding the additional extension a
big deal.  In the latter case, adding another way of expressing the
same data should be pretty trivial (although, obviously, an excellent
way to introduce pointless bugs).

A

-- 
Andrew Sullivan
[email protected]
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg