Subject: RE: [ietf-provreg] EPP Implementation Test Matrix

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 6 Jul 2006 13:45:25 -0400

> -----Original Message-----
> From: Klaus Malorny [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 12:55 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [ietf-provreg] EPP Implementation Test Matrix
> 
> Hollenbeck, Scott wrote:
> > Here's the first draft of a complete EPP test matrix.  I've tried to
> > document the results of testing between two client 
> implementations and
> > three server implementations, with all of the software 
> being developed
> > independently.  I'm sharing it here so that all can see 
> what was done,
> > how I'd like to report the results, and to catch any errors or
> > omissions.  Each row should have at least one "X" in it to 
> confirm that
> > the feature was tested and confirmed in at least two 
> implementations.  I
> > believe we've met that requirement.
> > 
> > Please clue me in if I've missed anything.
> > 
> 
> Hi Scott,
> 
> I am not sure whether I understand why you send this to this 
> list. We can't 
> verify that anyway. For example:

I sent it to the list because advancement to draft status requires
completion of an implementation report.  That report, which must include
a description of the features and test results, should be something
shared with list members before it gets sent to the IESG.  I want to let
others see what's been reported to me so that they can compare the
reported result with their own experience.

> 
> >   <response>                        |  X  |  X  |  X  |  X  
> |  X  |  X
> > |
> >     OPTIONAL <value>                |  X  |  X  |  X  |  X  
> |  X  |  X
> 
> How can I verify that? I don't know what DotRegistrar and Key 
> Systems get from 
> Afilias and Neulevel, but I know what we get, and because of 
> this, I wouldn't 
> put an 'X' here. Your draft 
> (draft-hollenbeck-epp-rfc3730bis-01, the latest I 
> could find) says:
> 
>           Zero or more OPTIONAL <value> elements that 
> identify a client-
>           provided element (including XML tag and value) that caused a
>           server error condition.
> 
> Well, Afilias and Neulevel put a lot of stuff into the value 
> element, like 
> additional error codes, comments and so on, but nothing that 
> identifies a 
> client-provided element. If, for example, a domain:info 
> command fails because 
> the domain does not exist, I would expect the <value> element 
> to contain 
> "<domain:name>example.com</domain:name>" as the content, but 
> this does not 
> happen at the two registries.
> 
> This is not a special attack against Afilias and Neulevel in 
> favour of Verisign. 
> As I am not involved in our transition to EPP at Verisign, I 
> simply don't know 
> whether Verisign is any better and eats its own dog food.

This is precisely why I shared the matrix.  If your results differ, I
need to know what others have seen for test results.  If there are
differences of opinion we can talk about them to determine what really
needs to be in the boxes.

> Howsoever, I would be surprised if you would do anything but 
> to ignore my 
> objections -- as usual.

Ignore your "objections"?  Hardly.  There are multitudes of responses
from me in the list archives (such as this one) to confirm that you're
not being ignored when you participate in a productive dialogue.
However, don't expect me to respond to your opinions [1] that repeat old
arguments.  I'm not going there.

-Scott-

[1]
such as this one:
http://www.cafax.se/ietf-provreg/maillist/2006-06/msg00063.html

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 06 Jul 2006 22:19:06 +0200

Hi Scott,

It is not a question of "differences". It is a question of interpretation of the 
term "implemented and tested". What about the "<hello>" message, for example? 
Six "X". Really? Does any of the three registries work with a different 
transport layer than RFC 3734? Not that I am aware of. So how could you have 
tested the <hello> command if RFC3734 does not even mention it? Comparing 
RFC3730 and RFC3734 shows that it is at least unclear (if not contradicting) 
whether or not the client may send a "<hello>" message at the beginning of the 
communication (and cannot be tested therefore). My personal interpretation of 
your RFC3734 is, however, that the "<hello>" element is not allowed in TCP-based 
communications. Since the "<hello>" message is not a command, it is also unclear 
in RFC3730 how a server should react if it receives a "<hello>" message at any 
point in time after the server has sent the "<greeting>" message. Also not testable.

> arguments.  I'm not going there.

A single word comes to my mind: Idempotency. You are probably still convinced of 
this great property of EPP (in the way you have defined it).

- SCNR

> -Scott-

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