On 8/21/2015 10:16 AM, Michael König wrote:
>> Daniel Stenberg <daniel_at_haxx.se> hat am 20. August 2015 um 23:20 geschrieben:
>>
>>
>> On Wed, 19 Aug 2015, Michael König wrote:
>>
>> If you think you can get something like that written into the documentation
>> for this new option as well, my objections are squashed and I'll even help
>> writing up a test case for it. =)
> Deal!
> Keep in mind, that was quite likely the first time i ever modified/created
> manpages. I used a lot of copy&paste.

I think this would be a good option to expose in the command line tool
curl so I made some changes for that [1]. I also modified your terms
some. You short description of the option is 'Prevents TFTP options to
be send with RRQs/WRQs' which is complex for a short description. I
changed it to 'Do not send TFTP options requests' and also matched that
short description in several places. In the detail of the option it now
includes those facts in the description:

"Set \fIonoff\fP to 1L to exclude all TFTP options defined in RFC2347,
RFC2348 and RFC2349 from read and write requests (RRQs/WRQs)."

Also I removed your assertion that not sending the TFTP options will
make us conform to RFC1350. I may have overstepped on that, but I don't
know that it's a correct assertion (didn't read the RFC).

Now that we're not sending options (tsize, blksize, timeout), someone
will need to check that there is not any code that depends on any of
those being sent. As far as I can tell no but someone experienced in
this protocol may want to take a look. The blocksize for example appears
will default to 512 so even if a user specifies a bigger blocksize and
the server doesn't return a blocksize 512 will be used.

[1]:
https://github.com/jay/curl/compare/master...jay:tftp_no_options?expand=1

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-08-24