RE: [ietf-provreg] EPP Implementation Test Matrix

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] 
> Sent: Thursday, July 06, 2006 12:55 PM
> To: Hollenbeck, Scott
> Cc: ietf-provreg@cafax.se
> 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