BIND 10 #2124: RFC 6594 for SSHFP

[BIND 10 Development]

#2124: RFC 6594 for SSHFP
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120731
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  libdns++                           |  Estimated Difficulty:  2
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 - I suspect it now allows >255 textual values.  We need test cases for
   them, and hey should be rejected correctly.
 - I'd add tests for the "from wire" cases (against some uncommon
   algorithms/types)
 - We need a changelog for this fix.
 - I made some (unrelated) style cleanups.
 - I'd make lines like this shorter:
 {{{#!cpp
     EXPECT_NO_THROW(const generic::SSHFP rdata_sshfp("0 1
 123456789abcdef67890123456789abcdef67890"));
 }}}
   So they won't be too long or we won't have to fold them.  For the
   purpose of the test, the fingerprint should be as simple as "1234"
   etc.
 - I'm not sure if this change is a good one:
 {{{#!diff
 -    EXPECT_THROW(const generic::SSHFP rdata_sshfp("1 2 foo bar"),
 InvalidRdataText);
 +    EXPECT_THROW(const generic::SSHFP rdata_sshfp("1 2 foo bar"),
 isc::BadValue);
 }}}
   In some sense it makes sense as it correctly catches what the test
   intends to catch (the bad part is "foo bar", and the hex decoder
   throws BadValue).  But from the caller's point of view, it should be
   more convenient and consistent if any bogus textual input generally
   results in `InvalidRdataText`.  In that sense I guess the better fix
   is to catch `BadValue` from `decodeHex()` and convert it to
   `InvalidRdataText`.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2124#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development