--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
