RRC and sign_only

[Greg Hudson]

On Wed, 2008-12-17 at 19:09 -0500, Jeffrey Hutzelman wrote:
> I have to agree with Love here.   Essentially what you're saying is that if 
> you use this API, it might not interoperate, because it cannot successfully 
> decode anything that an RFC4121 implementation might send.

If you are decoding an RFC4121 message, you will use the API in stream
mode (or just use the non-iov API).

I'm not sure you're understanding the situation at hand here (although I
believe Love is), so I'm struggling to find a good analogy.  If the wire
format were XML, then you might imagine an analagous API which can be
used in two modes:

  (1) "Here is an XML document to decode into a DOM" (analagous to
stream mode)

  (2) Here is a header tag, some body content, and a trailer tag; please
construct a DOM (analagous to non-stream mode)

In the first case, the API is acting as an XML decoder and should parse
everything the XML standard talks about.  In the second case, there is
no particular reason to believe that the API is processing a well-formed
XML document, and might reasonably impose additional restrictions such
as "no comments alongside the header tag".

I believe the analogy to Love's argument is that, even in the second
case, the API might be being used to process a well-formed XML document.
But I'd say that possibility is merely coincidental, and does not bind
the API (in that usage mode) to honor all aspects of the standard.

>From a practical perspective, as I understand the situation, honoring
all rrc values has no benefit and requires using some grotty
vector-rotation code which would be difficult to adequately test.  So
I'm inclined toward the philosophical perspective that we don't need to
do it, even if the argument seems a little tortured to some.