--On Sunday, 02 December, 2007 00:25 +0100 "Peter J. Holzer" <[EMAIL PROTECTED]> wrote: >... > This is an incompatible change in the protocol, as a client > conforming to RFC 2821 is of course perfectly correct in > sending the optional parameter while the server conforming to > RFC 821 is equally correct in rejecting it. >... > For some reason, this was not used for > NOOP, but an incompatible change was made in the core protocol > (which I admit I don't understand: What is the purpose of this > parameter? Why was it added at all? To reflect actual usage or > just because somebody thought it might be useful?) My recollection is that DRUMS was trying to reflect existing practice. While I haven't searched the archives, the odds that this was done by accident and without discussion are very small. john
- Re: New Issue: NOOP clarification John C Klensin
- Re: New Issue: NOOP clarification Hector Santos
- Re: New Issue: NOOP clarification John C Klensin
- Re: New Issue: NOOP clarification Hector Santos
- Re: New Issue: NOOP clarification Tony Hansen
- Re: New Issue: NOOP clarification Glenn Anderson
- Re: New Issue: NOOP clarification Hector Santos
- Re: New Issue: NOOP clarification Glenn Anderson
- Re: New Issue: NOOP clarificati... Hector Santos
- Re: New Issue: NOOP clarifi... Peter J. Holzer
- Re: New Issue: NOOP clarifi... John C Klensin
- Re: New Issue: NOOP clarifi... Hector Santos
- Re: New Issue: NOOP clarifi... Frank Ellermann
- Re: New Issue: NOOP clarifi... Sabahattin Gucukoglu
- Re: New Issue: NOOP clarification Tony Hansen
- Re: New Issue: NOOP clarification SM
- Re: New Issue: NOOP clarification Hector Santos
- Re: New Issue: NOOP clarification Valdis . Kletnieks
- Re: New Issue: NOOP clarification Hector Santos
- Re: New Issue: NOOP clarification Valdis . Kletnieks
- Re: New Issue: NOOP clarification Hector Santos
