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

Andrew, 10 years of reading your emails and I am still amazed with how well
you write them,.....

Your thoughts on ccTLDs  are so true in the current state, maybe that
balance changes after a couple of new TLDs application rounds, maybe not.

ccTLDs have no entity like ICANN to try and enforce some common practises,
with good reason, they represent sovereign states so it's appropriate they
are independent. However it would be in everyone's interest to reduce work,
effort and confusion by forming standards.

A strategy of making client implementation easier is a  good idea, but it
needs to extend to the registrant and storefront as well. For example
different terminology in different registries for a data element or
modifier/attribute is confusing for a domain user even if we find a way to
make epp client implementation cheaper (look at our discussions of language
versus script even).  I feel like we are just going to have to work through
every common extension and its variations in order to consolidate to a
single standardized version - no easier shortcuts .  That means that each
extension we would try and to do this with has to be flexible enough for
everyone's use cases.  I feel sometimes we get debating uselessly over the
validity of a use case when there's an easy option to accommodate multiple
use cases.  Its really seldom that accommodating one use case means shutting
out another one altogether - although it does happen.

So then, how do we organize to try and make some progress here?  Does
everyone think we should try and organize in the first place?

-M

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Andrew Sullivan
Sent: January-05-12 2:21 PM
To: [email protected]
Subject: Re: [provreg] 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

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