BIND 10 #2387: support generic version of rdata::createRdata(text) in DNSKEY, NSEC3, NSEC3PARAM

[BIND 10 Development]

#2387: support generic version of rdata::createRdata(text) in DNSKEY, NSEC3,
NSEC3PARAM
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  libdns++      |                    Milestone:
            Keywords:                |  Sprint-20130423
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  5             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  8
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by muks):

 Replying to [comment:25 jinmei]:
 > It'd depend on how likely the difference would be noticed.  I guess
 > it's quite minor (something that could be noticed in crafted test
 > cases, etc), and, if so, I'd unify these changes into a single summary
 > changelog entry and note the compatibility issue there (not listing
 > each affected rdata types, but as a general note).

 I was unsure whether to add a `ChangeLog`, which is why I asked. We'll
 leave it to later when a single `ChangeLog` message is made.

 > On the latest branch:
 > - I made a few suggested editorial changes to documentation

 These look fine.

 > - may be a matter of taste, but I'd personally not bother to assert
 >   the condition here
 > {{{#!cpp
 >         // token is now assured to be of type STRING.
 >         assert(token.getType() == MasterToken::STRING);
 >
 >         token.getString(keydata_substr);
 > }}}
 >   for two reasons: first, I personally think assert() can be too
 >   strong for checking condition beyond a class boundary.  Secondly,
 >   `MasterLexer` is generally designed and implemented to be safe
 >   against this type of mismatch: `getString` throws an exception if
 >   it's not of a string type.  leaving a comment on this is fine,
 >   though.  I'd leave it to you, but if you agree please note there are
 >   several of such asserts in the branch.

 I've reverted the commit which introduced these asserts.

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