BIND 10 trac2387, updated. 9a045959025fb0961c7bf2eb09603f7604d5cbee [2387] Move text about missing key data to the constructor API doc

[BIND 10 source code commits]

The branch, trac2387 has been updated
       via  9a045959025fb0961c7bf2eb09603f7604d5cbee (commit)
      from  82fc64bf97eb7d50e22edcac28cefe0b93b9a7ff (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 9a045959025fb0961c7bf2eb09603f7604d5cbee
Author: Mukund Sivaraman <muks at isc.org>
Date:   Tue Apr 9 11:18:28 2013 +0530

    [2387] Move text about missing key data to the constructor API doc

-----------------------------------------------------------------------

Summary of changes:
 src/lib/dns/rdata/generic/dnskey_48.cc |   26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

-----------------------------------------------------------------------
diff --git a/src/lib/dns/rdata/generic/dnskey_48.cc b/src/lib/dns/rdata/generic/dnskey_48.cc
index d3a923a..3dadde9 100644
--- a/src/lib/dns/rdata/generic/dnskey_48.cc
+++ b/src/lib/dns/rdata/generic/dnskey_48.cc
@@ -63,7 +63,10 @@ struct DNSKEYImpl {
 /// The Protocol and Algorithm fields must be within their valid
 /// ranges. The Public Key field must be present and must contain a
 /// Base64 encoding of the public key. Whitespace is allowed within the
-/// Base64 text.
+/// Base64 text. It is okay for the key data to be missing. BIND 9 seems
+/// to accept such cases. What we should do could be debatable, but
+/// since this field is algorithm dependent and our implementation
+/// doesn't reject unknown algorithms, we are lenient here.
 ///
 /// \throw InvalidRdataText if any fields are out of their valid range,
 /// or are incorrect.
@@ -97,6 +100,15 @@ DNSKEY::DNSKEY(const std::string& dnskey_str) :
     impl_ = impl_ptr.release();
 }
 
+/// \brief Constructor from InputBuffer.
+///
+/// The passed buffer must contain a valid DNSKEY RDATA.
+///
+/// The Protocol and Algorithm fields are not checked for unknown
+/// values.  It is okay for the key data to be missing. BIND 9 seems to
+/// accept such cases. What we should do could be debatable, but since
+/// this field is algorithm dependent and our implementation doesn't
+/// reject unknown algorithms, we are lenient here.
 DNSKEY::DNSKEY(InputBuffer& buffer, size_t rdata_len) :
     impl_(NULL)
 {
@@ -111,10 +123,8 @@ DNSKEY::DNSKEY(InputBuffer& buffer, size_t rdata_len) :
     rdata_len -= 4;
 
     vector<uint8_t> keydata;
-    // If key data is missing, it's OK. BIND 9 seems to accept such
-    // cases. What we should do could be debatable, but since this field
-    // is algorithm dependent and our implementation doesn't reject
-    // unknown algorithms, we are lenient here.
+    // If key data is missing, it's OK. See the API documentation of the
+    // constructor.
     if (rdata_len > 0) {
         keydata.resize(rdata_len);
         buffer.readData(&keydata[0], rdata_len);
@@ -187,10 +197,8 @@ DNSKEY::constructFromLexer(MasterLexer& lexer) {
     lexer.ungetToken();
 
     vector<uint8_t> keydata;
-    // If key data is missing, it's OK. BIND 9 seems to accept such
-    // cases. What we should do could be debatable, but since this field
-    // is algorithm dependent and our implementation doesn't reject
-    // unknown algorithms, we are lenient here.
+    // If key data is missing, it's OK. See the API documentation of the
+    // constructor.
     if (keydata_str.size() > 0) {
         decodeBase64(keydata_str, keydata);
     }