Daniel Pitts
5/20/2015 2:38:00 PM
On 5/19/15 10:17 PM, Michael Griffin wrote:
> On 5/19/2015 7:25 PM, Daniel Pitts wrote:
>> I apologize if this is off topic, not quite sure where else to ask.
>>
>> I'm implementing my own Telnet library in Java (just because). I'm
>> wondering if my library should allow sending a "WONT" or "DONT" that was
>> otherwise unsolicited. I'm also wondering if my library should reply to
>> unsolicited "DONT" or "WONT" requests with the "WONT" or "DONT" reply
>> respectively. The RFC isn't quite clear on that part of the contract.
>>
>> All of this is assuming that I've already sent a DO and got a WILL, or
>> visa versa.
>>
>>
>> Thanks,
>> Daniel.
>
> Well usually the server is the one that initiates the negotiation.
My library's first use is actually a server, but Telnet is fully
symmetric at the protocol layer, so "usual" isn't what I was thinking of.
>
> If it's a client, then it should usually respond back with what the
> server is querying like BINARY, ECHO, NAWS etc.. But of course if an
> expected response is not received by the client, it is allowed to ask
> the server for it's preference. Unsolicited response are allowed, and
> can either be responded to, or ignored.
>
> You want to be aware of possible loops where responses keep exchanging
> back and forth between the server and client well after they been answered.
>
> Michael
> telnet://htc.zapto.org
>
I'm thinking in particular after having said "IAC WILL <FOO>", and
receiving a "IAC DO <FOO>", can I later sao "IAC WONT <FOO>" to stop
FOOing? And when I do that, will I receive an acknowledgement?
Another way to ask this is:
If I received a "IAC DO <FOO>" after a "IAC WILL <FOO>", the other side
has the ability to change its mind "IAC DON'T <FOO>". When they do
that, should I reply with "IAC WON'T <FOO>", or just silently accept the
new state of affairs?
I think I realized the answer: If I receive a command that changes my
state, then I should acknowledge with the new state. Defensive
programming says I shouldn't expect an acknowledgement, but handle one
cleanly.
If I disable an option changes my handling of the data stream, I
shouldn't disable the processing until the byte after the response of
IAC DON'T/WON'T.