Hi Hector,
On Fri, Jun 28, 2013 at 11:56 AM, Hector Santos <hsantos(_at_)isdg(_dot_)net>
wrote:
I believe this is all part of improving the IETF Electronic Diversity
picture. Just like we have to deal with greater people personal
globalization diversity issues, there is also greater technology and legal
diversity issues to deal with. So many tools, so many languages, so many
OSes, so many devices and communications API platforms, where are the
proposals for better, new "IETF Global Commons?" Guidelines for technical
writing for the new world engineers to use, etc.
I think that computational code written in C, pretty much the lowest
common denominator, is just fine. I don't think there is any greater
diversity now that then was 10 or 20 years ago at that level. In fact,
I think there is less.
For me, when I saw this RFC, the things crossed my mind:
- I have trouble with the licensing statement. The RFC describes public
domain technology. It requires passing this thru your lawyer(s) to see if
it can used in our commercial product lines.
Sorry, the standard simplified BSD license is required for code in
RFCs. The authors couldn't change it. But if you are doing a serious
commercial product and you don't have a lawyer checking such things
anyway, you are a fool.
- Far too big to distribute via a RFC. Provide a link to some RFC site.
Note, I'm just saying in general. I did not read in detail if
the RFC already included links to the official source code.
Nonsense. An RFC should be self contained and IO don't see what's "too
big" about this one. The code is in a relatively compact region of the
RFC, so you can read the text and skip the code, if you want, without
undue effort.
- Because it was too big, it requires a stripper/parser, although a good
power programmer can quickly macro-clean it up. The RFCSTRIP tool, well,
what language is that? I'm not an *nix person. So this adds to the
complexity for the Windows shops to get at these hashing functions. Of
course, its a piece of cake for a sharp programmer, but even the sharpest
knives eventually get dull.
This is just nonsense. If you are going to do anything serious with
code, you need a source code editor. With that, it is no big deal to
extract and test the code. Although I would agree that making the
RFCSTRIP tool available over the web, as many other tools are, would
be reasonable.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com
--
HLS
On 6/28/2013 4:53 AM, Dearlove, Christopher (UK) wrote:
I'd actually tried the authors, but no reply yet (only a few days). I also
tried the RFC Editor thinking they might have e.g. XML from which extraction
might have been easier, but also no response yet. And I had found several
libraries, but not the RFC code. I can't see any suggestion that the library
you indicate includes that code, it also bills itself as a C++ library,
which the RFC code is not (and also not what I want, but that's not a
subject for this list).
But the broader point is that if it's worth the IETF publishing the code
as an RFC, it's worth making the code available straightforwardly.
For me, a thanks to Tony Hansen, who did the extraction for me. (That
makes me feel a little guilty, why should he do my work I could have done?)
But the point of posting on this list was to say that the code should be
available so that each person wanting that code doesn't have to do that
again.
Christopher