Subject: RE: [ietf-provreg] registries, XML & EPP (again)

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 5 Oct 2005 07:16:08 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Klaus Malorny
> Sent: Wednesday, October 05, 2005 6:26 AM
> To: [email-masked]
> Subject: [ietf-provreg] registries, XML & EPP (again)
> 
> 
> 
> Hi all,
> 
> digging deeper into the EURid EPP specs I discovered 
> something that is in my 
> humble opinion a bit more serious than the prefix problem. It 
> looks like that 
> they took the XML schema files of the domain and contact 
> objects (RFC 3731, 
> 3733) and deliberately modified them, like adding a new 
> contact type or changing 
> whether elements are mandatory or not. I am not completely 
> aware of all changes, 
> as the schema files are not available yet. While the changes 
> themselves are not 
> a problem at all, EURid still associates these new schemes 
> with the IETF 
> namespaces, namely urn:ietf:params:xml:ns:contact-1.0 and 
> urn:ietf:params:xml:ns:domain-1.0. Isn't this something that 
> should really be 
> avoided for the sake of the clarity and compatibility? 
> Technically, it is not a 
> problem to use any other URI, like they did for their 
> proprietary extensions anyway.
> 
> Please don't misunderstand me, I do not want to start an 
> EURid or whatever 
> registry bashing here, but the least what we need is a 
> standard that isn't one 
> (for whatever reason). Lessons like SQL or HTML have shown 
> where something can end.

More than just "should really be avoided".  "MUST NOT be done"!

Those URIs are the unique, registered identifiers for the EPP schemas
and namespaces.  They identify the specs documented in the RFCs.  Change
the schemas and you have something new, different, and EPP-like that
MUST NOT (in 2119 terms) be identified using the same URIs.

-Scott-

---

From: maarten <[email-masked]>
Date: Thu, 06 Oct 2005 14:47:08 +0200

Hi all,

The prefix problem is actually a bug in our documentation:  no specific
prefixes are required.
Concerning the IETF namespace URI's :  we will use our own URI's for all
the schemas that we have modified.

Maarten Bosteels
software developer DNS Belgium

---

From: Klaus Malorny <[email-masked]>
Date: Tue, 18 Oct 2005 18:01:06 +0200

Hi all,

while EURid has updated their specs in a thankworthy way, this still has a 
slightly bad aftertaste, as even the namespace of the framing XML (i.e. the 
"urn:ietf:params:xml:ns:epp-1.0" namespace) was required to be changed due to 
the introduction of new commands. I have the feeling that quite a lot of new 
registrars that download open source EPP implementations will have to learn the 
hard way that EPP is not always EPP. That way, it could be questionable whether 
EURid's protocol even deserves the name "EPP" at all.

On the other hand, while EPP does provide a legal means to create additional 
commands via the second level "<epp:extension>" element, one should rethink the 
fixed command set of the "commandType" schema type when an update of EPP is 
considered. Having an additional command as an extension outside of the 
"<command>" element, it is not clear that the typical command/response behaviour 
shall apply to this command as well.

regards,

Klaus

___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      [email-masked]             Tel. +49 231 9703 0

---

From: maarten <[email-masked]>
Date: Wed, 19 Oct 2005 14:10:39 +0200

Klaus Malorny wrote:

> Hi all,
>
> while EURid has updated their specs in a thankworthy way, this still 
> has a slightly bad aftertaste, as even the namespace of the framing 
> XML (i.e. the "urn:ietf:params:xml:ns:epp-1.0" namespace) was required 
> to be changed due to the introduction of new commands. I have the 
> feeling that quite a lot of new registrars that download open source 
> EPP implementations will have to learn the hard way that EPP is not 
> always EPP. That way, it could be questionable whether EURid's 
> protocol even deserves the name "EPP" at all.
>
I agree that we should have used Protocol Extension for adding our extra
commands, but it's probably a bit late for that.

> On the other hand, while EPP does provide a legal means to create 
> additional commands via the second level "<epp:extension>" element, 
> one should rethink the fixed command set of the "commandType" schema 
> type when an update of EPP is considered. Having an additional command 
> as an extension outside of the "<command>" element, it is not clear 
> that the typical command/response behaviour shall apply to this 
> command as well.

How about adding an empty <extra/> element to the choice in commandType
for all the extra commands that one wants to define:

<command>
    <extra/>
    <extension>
       <eurid:ext
          xmlns:eurid="http://www.eurid.eu/xml/epp/eurid-1.0"
          xsi:schemaLocation="...">
          <eurid:trade>
             <eurid:domain
                xmlns:domain="..."
                xsi:schemaLocation="...">
                <eurid:registrant>epp11</eurid:registrant>
                <eurid:trDate>2010-10-10T10:10:10.0Z</eurid:trDate>
                ...
             </eurid:domain>
          </eurid:trade>
       </eurid:ext>
    </extension>
   <clTRID>abc-456</clTRID>
</command>

This way it would be clear that the typical command/response behaviour
applies.

Maarten Bosteels
DNS BE Developer

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Oct 2005 09:22:56 -0400

At 18:01 +0200 10/18/05, Klaus Malorny wrote:

>XML (i.e. the "urn:ietf:params:xml:ns:epp-1.0" namespace) was 
>required to be changed due to ...

What bothers me is that there is a second instance of a registry, in 
this other case, avoiding EPP and instead building their own 
protocol.  I am not making a judgement call on the wisdom of 
prefering a home grown effort over a standard, but rather am 
concerned that the standard wasn't "good" enough for them.

See: 
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-enum-epp.pdf

The talk is somewhat mistitled in the agenda, why DENIC didn't use 
EPP for ENUM.  The reason is simply that DENIC doesn't use EPP for 
anything.  (;))  From slide 7 onwards though is the interesting stuff 
- why DENIC doesn't use EPP for anything.

This is a cry for "use the IETF for what it is for."  I would hope to 
see a detailed critique outlining why EPP is failing to meet the 
needs of the community come in, and not a feeling that EPP should be 
shunned.  The definition of EPP by the IETF is not to be taken as a 
royal edict.  It should be the collective wit and wisdom of us wise 
guys.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

True story:
Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis
to get home from a conference.  (Cities changed to protect his identity.)

---

From: janusz <[email-masked]>
Date: Wed, 19 Oct 2005 09:58:42 -0400

> that the typical command/response behaviour shall apply to this 
Klaus,
if "commandType" schema type was extended as you are proposing then EPP 
protocol would have more than one way of creating new EPP commands. What 
should be then the policy for protocol implementers for choosing one way 
over the other? Do you have any particular criteria in mind?

Janusz

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 19 Oct 2005 18:08:31 +0200

Edward Lewis wrote:
>> to be changed due to ...
> this other case, avoiding EPP and instead building their own protocol.  
> I am not making a judgement call on the wisdom of prefering a home grown 
> effort over a standard, but rather am concerned that the standard wasn't 
> "good" enough for them.
> 
> See: 
> The talk is somewhat mistitled in the agenda, why DENIC didn't use EPP 
> for ENUM.  The reason is simply that DENIC doesn't use EPP for 
> anything.  (;))  From slide 7 onwards though is the interesting stuff - 
> why DENIC doesn't use EPP for anything.
> 
> see a detailed critique outlining why EPP is failing to meet the needs 
> of the community come in, and not a feeling that EPP should be shunned.  
> The definition of EPP by the IETF is not to be taken as a royal edict.  
> It should be the collective wit and wisdom of us wise guys.

Hi Edward,

being a member of the technical advisory committee of DENIC, I strongly 
supported the decision of DENIC to implement its own protocol and not EPP, and I 
can explain why. At the time the decision was made, EPP was still in the draft 
state, and the underlying model of EPP was just incompatible with the DENIC 
model, most notably the inability to deal with a "hostless" structure. In 
following drafts EPP became more flexible regarding this (via the hostAttr 
element). However, still today there are quite a lot differences in the models, 
starting at additional contact fields, multiple registrant contacts per domain, 
different transfer mechanisms and requirements and special commands, like the 
transit or changeholder commands. A possible EPP solution would be either to 
adopt the generic EPP model or to build a large set of extensions for EPP to 
allow the representation of DENIC's model as EPP. The first case would not only 
have had a large impact to DENIC itself, but to all DENIC registrars as well. 
Large amounts of money would have been burnt for the developments at DENIC and 
the registrars, and the transition from the DENIC model to the EPP model would 
not have been an easy one. The other solution would have had the clear 
disadvantage that every single XML element added as an extension of EPP 
diminishes the benefit of EPP, namely to have a generic interface that can be 
used with a generic toolkit and a generic registrar software. Any solution 
in-between merely inherits the disadvantages and not the advantages of both 
solutions.

Sorry to say that, but in the beginning of the provreg working group Scott and 
others of the gTLD faction were just too confined to the Verisign model and 
fully ignored the ccTLDs, their needs and their models. IMHO this discouraged 
many ccTLDs from participating. EPP is indeed "extensible", but in some aspects 
just not at all.

While I think it is reasonable that existing registries go their own way in 
dealing with registry protocols for their own benefit and the benefit of their 
registrars and customers, I believe that new registries should adopt EPP with as 
few extensions as possible and with a registry model as compatible as possible, 
even though I do not consider myself as a big friend of EPP. Therefore I am 
disappointed that EURid did not manage to provide a cleaner EPP implementation 
within two years or so, but using the very same concepts of the .be registry.

regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 19 Oct 2005 18:13:14 +0200

> over the other? Do you have any particular criteria in mind?

Hi Janusz,

well, as I said, that they behave like other commands, i.e. that the answer is a 
<response> element with the known structure.

regards,

Klaus

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Oct 2005 12:30:40 -0400

At 18:08 +0200 10/19/05, Klaus Malorny wrote:

I have no qualms with anyone implementing their own system, even if 
there is a so-called standard approach out there. 
(Contempt-of-standards is not a crime.)  However, doing this is what 
will kill off the IETF.  The IETF has been, is, and can be a valuable 
resource to the developers of the Internet so long as we fight decay 
of it's function.

>many ccTLDs from participating. EPP is indeed "extensible", but in 

No reason to be sorry for that feeling.  But the question is - in 
what way did the discouragement of the ccTLDs become a 
self-fulfilling prophecy?

(One disclaimer - I am going to label camps as ccTLD and gTLD.  Take 
this as a broad brush.  In particular, my current employer is both a 
ccTLD and a gTLD.  The camps aren't so neatly distinct.)

As one of the chairs of the group, I did my best to get wide review. 
(I was hampered by a limited budget for this as my then employer is 
not any kind of a stakeholder in the process.)  Approaching some 
ccTLDs when I could get out, I was told that input was too expensive. 
The only organizations that expended energy were those with a gTLD 
mission.

It wasn't until I got one ccTLD person to speak up about the 
host-less issue that the specification softened on this.  It wasn't a 
matter of getting a voice of a ccTLD to do this, it was a matter of 
trying to figure out what middle ground was available, i.e., how to 
bend the work to suit all comers.  There were rumors floating that 
the host-less approach was in conflict with EPP, but until someone 
clearly said why and was able to sketch a solution, rumors were just 
that.  (Engineers don't deal in rumor.)

When the WG began in 2001, nearly all of the voices were gTLD fed. 
ccTLDs didn't pay much attention as the first blocks of concrete set. 
Over time EPP got wider review which translates into rethinking early 
decisions.  Any feelings of "let's not do this again" by the 
incumbents towards the newcomers is just human nature.  It will 
continue to be this way until the Internet serves the entire planet. 
Such inertia needs to be fought, with even more energy by the newer 
newcomers or else the entire effort will collapse into fragmented 
bickering.

My words aren't about "anyone vs. the Verisign model," although I can 
understand that sentiment.  This is about trying to make the IETF 
work.

What can be done?  If you were to submit a draft that gives 
engineering details of what is wrong with EPP for your case, perhaps 
there is a way to define EPP2 that is even more general.   Then 
again, maybe not - TV has PAL and NTSC formats.  The people that 
"suffer" are those running the clients.

True story:

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 19 Oct 2005 19:45:18 +0200

Klaus Malorny <[email-masked]> 2005-10-18 18:31
> "urn:ietf:params:xml:ns:epp-1.0" namespace) was required to be changed due 
> to the introduction of new commands. I have the feeling that quite a lot of 
> new registrars that download open source EPP implementations will have to 
> learn the hard way that EPP is not always EPP. That way, it could be 
> questionable whether EURid's protocol even deserves the name "EPP" at all.

These ``small'' differences can easily be hidden in the client,
provided that it is flexible enough.

Thus, for me, they do not show that there are problems in EPP. Just
that people have different needs, and that it is impossible to find a
solution that works for anyone. It creates a greater burden on
registrar/client software, but, in my view, nothing impossible to
achieve.

At least, this is the kind of view I try to have when working on my
own implementation (which, BTW will soon fully support EURid and, at
the same time, any other EPP registry).

Maybe now that more people are aware of EPP, even if they finally do
not decide to use it for whatever reasons, they can participate even
more towards the next iteration, and this is why I totally agree with
the idea of putting in written what problems/differences they see, to
make sure it will taken into account.

-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/>

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 20 Oct 2005 00:34:41 +0200

Edward Lewis wrote:

> 
> No reason to be sorry for that feeling.  But the question is - in what 
> way did the discouragement of the ccTLDs become a self-fulfilling prophecy?
> 
> As one of the chairs of the group, I did my best to get wide review. (I 
> was hampered by a limited budget for this as my then employer is not any 
> kind of a stakeholder in the process.)  Approaching some ccTLDs when I 
> could get out, I was told that input was too expensive. The only 
> organizations that expended energy were those with a gTLD mission.
> 
> It wasn't until I got one ccTLD person to speak up about the host-less 
> issue that the specification softened on this.  It wasn't a matter of 
> getting a voice of a ccTLD to do this, it was a matter of trying to 
> figure out what middle ground was available, i.e., how to bend the work 
> to suit all comers.  There were rumors floating that the host-less 
> approach was in conflict with EPP, but until someone clearly said why 
> and was able to sketch a solution, rumors were just that.  (Engineers 
> don't deal in rumor.)
> 
> decisions.  Any feelings of "let's not do this again" by the incumbents 
> towards the newcomers is just human nature.  It will continue to be this 
> way until the Internet serves the entire planet. Such inertia needs to 
> be fought, with even more energy by the newer newcomers or else the 
> entire effort will collapse into fragmented bickering.
> 
> understand that sentiment.  This is about trying to make the IETF work.
> 
> What can be done?  If you were to submit a draft that gives engineering 
> details of what is wrong with EPP for your case, perhaps there is a way 
> to define EPP2 that is even more general.   Then again, maybe not - TV 
> has PAL and NTSC formats.  The people that "suffer" are those running 
> the clients.
> 

Hi Edward,

I cannot say who's fault it is. I think I have brought up some valid reasons 
for an existing registry with a proprietary structure not being interested in 
EPP. Beyond that, I can only speculate, like that they didn't want to 
participate because of the major role of Verisign. To get the real causes, you 
have to ask the registries themselves. In addition, I don't know what efforts 
the heads of the WG made to integrate the ccTLDs into the development process.

Anyhow, in my personal retrospective, my question is whether the goal of EPP is 
an illusion. To be honest, I have not a big insight in the thinking of the 
ccTLDs, but I think they have their reasons for not wanting to become a 
"generic" registry, distiguishable from other registries only by the TLD label. 
However, the goal of a protocol is to unify, to harmonize, to narrow things to 
the essence. The "Extensible" in EPP is from that point of view already a 
contradiction. If it is not limited to extensions also defined by the IETF, it 
gives freedom to the registries on the one hand, but destroys the benefits of 
the protocol on the other hand. Please don't misunderstand me, I do not want to 
devaluate Scott's and all others' work (well, execpt for the wrong statement 
about idempotency...), and EPP as it is has definitely its positive sides, but 
my conclusion is that the final goal cannot be reached. Therefore I am not a 
big proponent of the EPP idea.

As you asked, what can be done, there are indeed areas which I would like to 
have more extensibility or extensiblity at all:

- the command types, as mentioned
- the error codes
- the contact roles in domains
- the status values of contacts, hosts and domains

But taking into account what I have said above, the question is whether an EPP2 
(instead of an EPP1.x that just fixes problems that have been discussed 
recently) really makes sense. And of course, one can solve the 
non-extensibility of these elements by the current extension mechanism.

regards,

Klaus

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Oct 2005 20:48:51 -0400

At 0:34 +0200 10/20/05, Klaus Malorny wrote:

>an illusion.

That is a good point.  But for the sake of technical curiosity, 
knowing the limits of a protocol's usefulness is as important as 
knowing how to extend a protocol.

>The "Extensible" in EPP is from that point of view already a contradiction.
>If it is not limited to extensions also defined by the IETF, it gives freedom
>to the registries on the one hand, but destroys the benefits of the protocol
>on the other hand.

Anyone is free to implement extensions.  The crucial element though 
is to get the extension's schema recognized so that clients can make 
use of the extension.  (Of course - only the clients that need it.)

I hope that it is not the IETF that defines extensions, but rather 
that the IETF reviews the extensions documented and voluntarily 
submitted for review.  Scott's more recent extensions were not 
mandated into being by the IETF.

>(well, execpt for the wrong statement about idempotency...)

I agree(d) with you on that one, even if I didn't post anything about 
that.  When the WG reviewed the idempotency, no one saw the client 
vs. client interactions.

True story:

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Oct 2005 12:42:57 -0400

On Wed, Oct 19, 2005 at 06:08:31PM +0200, Klaus Malorny wrote:
> the clear disadvantage that every single XML element added as an extension 
> of EPP diminishes the benefit of EPP, namely to have a generic interface 
> that can be used with a generic toolkit and a generic registrar software. 

I hear this all the time, and it troubles me.  The point of the
extension mechanism is that it should be fairly trivial for an
extension to be prepared and made available.  Since servers can
announce their capabilities when negotiating connection, what is the
overwhelming barrier?  It it just a namespace problem, or are people
discovering that extensible servers or clients are really that tough
to build?

If it's the _former_ problem, all we need is a namespace registry,
right?  If it's the latter, what would make the problem less
difficult to solve?  A number of changes were recently proposed by
Scott.  Where were the people reporting all these problems when we
were trying to gather reports of experience?  (Once again, I'm
probably overlooking something self-evident to everyone else, but
maybe you folks could hit me with the clue stick.)

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 21 Oct 2005 10:40:05 +0200

> maybe you folks could hit me with the clue stick.)

Hi Andrew,

this is a misunderstanding. It is not a problem how EPP negotiates the 
extensions. Also, _implementing_ extensions on server or client side on the 
protocol level is no rocket science, rather code monkey work (though the 
definition of extensions not).

It is more a philosophical question. If two registries belief there is a need to 
add a "language" field to the contacts, this will likely result in two different 
extensions. Why? Well, the one registry also adds a field for favourite colour 
to the contact, the other one also adds a field for the favourite car brand. 
Both won't separate the language field into a common extension that just takes 
care about the contact's language, which would, on the other hand, be the only 
correct way from a protocol's perspective. The uncontrolled extensibility of a 
protocol is the protocol's death. Take, for example, the Whois protocol aka RFC 
3912, which has its roots in 1982. This protocol is extremely extensible, but 
the value of it is negligible. There are likely no two implementations of the 
protocol by two unrelated entities that are compatible. Those registrars who 
have implemented ICANN's Registrar Transfer Policy for thin registries know what 
this means. So from a protocol's perspective, it is the best to nail down 
everything, and if any extensions are required, to have a standardization body 
to define them. However, from a broader view, the registry-registrar protocol is 
only a minor, although not unimportant, part of the registry. Here it looks like 
that the mountain has to come to the prophet, and not vice versa. Some 
registries do the move the mountain, some only partially, and others not at all.

regards,

Klaus

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 21 Oct 2005 12:22:29 -0400

On Fri, Oct 21, 2005 at 10:40:05AM +0200, Klaus Malorny wrote:

> favourite car brand. Both won't separate the language field into a common 
> extension that just takes care about the contact's language, which would, 
> on the other hand, be the only correct way from a protocol's perspective. 
> The uncontrolled extensibility of a protocol is the protocol's death. Take, 

This argument is nonsense.  It is simply a dogmatic insistence that
people can't compromise to make general operation smoother for
everyone, even if the cost of that is a slightly greater burden for
particular individuals.  If that is true, the IETF is a complete
waste of time.

It happens to be true that sometimes people act unco-operatively: the
"Tragedy of the Commons" is neither impossible nor unknown.  But it
isn't a law of nature, either; and the successful functioning of
commons in parts of the world during various historical periods
proves as much.[1]  

It is also lamentably true that some people in the registry community
are unwilling to co-operate to make things overall easier for
everyone over the long run.  That does not entail that protocols
designed to serve such co-operation are doomed; and in fact, the
extremely helpful comments I received from folks on this list (and
also, earlier, from Scott Hollenbeck and James Gould) when I raised
some issues that we at Afilias had experienced demonstrates to me
that co-operation is possible.  Others used some of their time to
help co-ordinate a response to a problem that I had.

> There are likely no two implementations of the [whois] protocol by
> two unrelated entities that are compatible. Those registrars who
> have implemented ICANN's Registrar Transfer Policy for thin
> registries know what this means. So from a protocol's perspective,
> it is the best to nail down everything, and if any extensions are
> required, to have a standardization body to define them. 

By this logic, HTML is also a failure, because of the ease with which
people were able to ignore the recommendations of the W3C and create
horrors like <blink> or <bgsound> tags.  X- headers in email are also
an abomination, because nobody can control them and so systems use
them in ways that aren't approved by your favourite official
standards dictator.  I don't see that such positions are tenable. 
That an extensible protocol may be made so flexible as to be no
protocol at all is hardly news.  But it's some sort of reverse
bald-man fallacy to assert therefore that every flexible protocol
will never work.

We do have a standards body for these things: it's the IETF.  If
some people don't like the way it works and the costs it imposes
(like, for instance, that one has to co-operate with others when the
standards are being designed), well, they'll go play in some other
sandbox in exactly the way you describe.  But of course, they're free
to do that anyway: the design of the Internet all but ensures that
the level of protocol we're talking about simply can't be enforced by
anyone, except maybe through contractual obligations.  

Now, this sort of standardisation is, of course, dependent on people
playing nice.  It turns out that every sort of reasonably happy human
endeavour works the same way.  You can make any city nominally safe
and clean through the means of a police state; but the safe, clean
cities we like are the ones where the residents mostly don't need to
be forced not to beat each other up and not to dump their garbage
wherever they happen to be standing.  And that requires the majority
of residents to co-operate.

A

[1] Note that this is not an argument that the Internet is a commons
or any other such side issue.

---

From: Klaus Malorny <[email-masked]>
Date: Sat, 22 Oct 2005 00:12:25 +0200

> particular individuals.  If that is true, the IETF is a complete

I didn't say that. People can compromise. If they believe they have a benefit 
from it, directly or indirectly. They won't if there aren't enough incentives.

> [...]
> horrors like <blink> or <bgsound> tags.

Hmm. Maybe you don't know. HTML is dead. HTML is the prototype of a failed 
standard in many ways. W3C is working for many, many years now to fix that.

> X- headers in email are also

Well, I can send e-mails to nearly everyone connected to the Internet without 
using X-headers. But I can't register a .us, .coop, .eu domain, for example, 
without using the appropriate proprietary extensions. I can do this only for 
vanilla registries, mostly gTLDs. There is a difference at least to me.

By the way, you are the one who wants to dictate every registry to use a 
standard, namely EPP. I just question the value of a standard that is 
practically incomplete for a non-negligible number of registries in the one 
hand, and too limited for them at the same time in the other hand.

regards,

Klaus

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 24 Oct 2005 09:08:03 -0400

On Sat, Oct 22, 2005 at 12:12:25AM +0200, Klaus Malorny wrote:
> 
> I didn't say that. People can compromise. If they believe they have a 
> benefit from it, directly or indirectly. They won't if there aren't enough 
> incentives.

Well, this is different from the position as you put it before, where
the suggestion is that the registries _can't_ compromise.  If you're
merely making the assertion that they _won't_, then it's a question
that is empirically satisfied.  But given that (for example) NeuStar,
VeriSign, and Afilias managed together to co-ordinate a response to
the ICANN redemption grace period, there's at least _prima facie_
evidence that your assertion is false.

> standard in many ways. W3C is working for many, many years now to fix that.

But it was nevertheless hugely successful, even if it's not pure. 
The point here, as I understand it, is at least partly "running
code"; and by that estimation, HTML was a wild success.  

> Well, I can send e-mails to nearly everyone connected to the Internet 
> without using X-headers. But I can't register a .us, .coop, .eu domain, for 
> example, without using the appropriate proprietary extensions. I can do 
> this only for vanilla registries, mostly gTLDs. There is a difference at 
> least to me.

First, there _are_ people who use X headers as tokens for various
things, which then extend the functionality of those systems (it
seems to me that I've had messages from a Lotus Notes user that
contained more X-headers than anything else).  I couldn't use that
functionality, because I didn't know what the headers meant.  Does
that meant that those particular X-headers are bad?  (I say, "No.")

More significantly, though, your argument above seems to be that,
because you have to use this or that extension to a base protocol to
express this or that unusual policy in a given registry, that proves
that the base protocol is not useful.  It's really a false dichotomy:
either the protocol can be used everywhere, or it's not a protocol. 
You're welcome to that view; but with respect, I think it's not one
consistent with a large portion of technical or even human
experience: "SQL" is still a useful name for something, even though
the way you express it when using Oracle, DB2, PostgreSQL, or MS SQL
Server are different.

> hand, and too limited for them at the same time in the other hand.

I don't want to dictate anything: use what you want.  I am
suggesting, however, that the limitations you are observing can be
solved by the creative use of the extension mechanism; and that
co-ordination on that front may be achieved through the IETF. 
Therefore, I claim it would be more helpful to suggest alterations or
extensions than it is to stand by and make sweeping claims about
disutility.  In my opinion, registries that adopt, extend, and
improve EPP have an advantage over those that stick with a different
base protocol.  This is a matter for empirical discovery, though; and
it'd be hard to test my hypothesis if we don't have any hold outs.

A

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 24 Oct 2005 18:28:22 +0200

> evidence that your assertion is false.

You likely did it because you believed that you would have a benefit from the 
cooperation. No contradiction to what I wrote.

> code"; and by that estimation, HTML was a wild success.  

Well, no doubt that HTML was a success. But mostly because it was broken by 
Netscape & MS, who introduced elements like the <font> element or various 
attributes for tables etc. that allowed the usersto "design" their pages for the 
first time instead of having them to look like scientific essays, and who wrote 
HTML parsers that forgave nearly every syntactical error of the author.

> that meant that those particular X-headers are bad?  (I say, "No.")

Please read what I have written. I never claimed that X-headers are bad. Also, 
in a closed user group, it is not a problem to use proprietary extensions.

> the way you express it when using Oracle, DB2, PostgreSQL, or MS SQL

Again, you interpret my words in a false way. I clearly indicated that it will 
become _less_ useful. Same applies to SQL.

> it'd be hard to test my hypothesis if we don't have any hold outs.

Sorry to say that, I don't know whether it is the language barrier and my bad 
English, your personal dislike of critism on EPP or even a breeze of arrogance 
that you constantly miss the point I am talking about. If you had read my 
previous postings carefully enough, you wouldn't fight on non-existing battle 
fields. Therefore, I regard any further discussion on this topic as a waste of 
my time. As I have to waste my time elsewhere, e.g. on implementing the EURid 
EPP extensions (@EURid: no personal attack, but a matter of fact), I won't 
continue the discussion.

regards,

Klaus