Ted, How do you wish to approach the "two implementation" issue? I've documented successful testing with one client and one server for the feature Harald noted. Should I try to discover who else has implemented the feature, or is this adequate to meet the "two independent implementations" requirement?
-Scott- > -----Original Message----- > From: Harald Alvestrand [mailto:[EMAIL PROTECTED] > Sent: Friday, November 10, 2006 7:53 PM > To: Hollenbeck, Scott; [email protected]; Ted Hardie > Subject: RE: Gen-ART review of draft-hollenbeck-epp-rfc3730bis-03 > > > > --On 10. november 2006 13:59 -0500 "Hollenbeck, Scott" > <[EMAIL PROTECTED]> wrote: > > > Thanks Harald. More info below. > >> - The reason for the change (in the draft), and whether or > >> not it affects > >> interoperability with old implementations > > > > Sure, I can add the reason in the appendix. Reality is that > > implementations have been doing what's now specified > instead of what's > > in the old RFC because the spec was wrong. The msgID isn't > needed to > > retrieve a message, only to ack and dequeue it, so it > doesn't need to be > > returned in the response. The current text confirms that an ack > > response is correctly identified with the ack command. > > Good. > > >> - That the tested implementations actually implement the > >> changed protocol, > >> not the RFC 3730 protocol (in the implementation report). > >> > >> The last is implicit in the fact that the implementation > >> reports refer to > >> the -bis documents, so this may be OK. IESG's call. > > > > I figured that a description of the tested implementations > belongs in > > the implementation report. It seemed out of place in the > -bis document. > > Yes, that's where I think it belongs. > > >> There is one feature that has only been tested for one > >> client/server pair: > >> <response><extValue>. It seems an easy value to support, so I > >> would not > >> think it worrisome - but it's a departure from the formal > >> requirements. > > > > I was working under the assumption that the requirement was > met because > > the client and server implementations were developed > independently. Two > > server implementations and 2 client implementations would > have been four > > implementations in total. > > We've discussed this a number of times; the MIB criteria, for > instance, are > explicit about 2 server implementations, but don't mandate 2 > clients, since > any MIB-walker can be used to verify that information is > present. But I > think the consensus has tended to end up with 2 clients, 2 > servers, since > they actually perform different roles - in this case, we have > only one > generation code and one parsing code for the element in question. > > Good point for clarification if we ever get around to > revisiting that text. > > I'd be happier with at least 2 servers that generate the > value. But I'll > leave that to the IESG; I don't see it as a big deal. > > Harald > > > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
