Because it's a standard, so we don't re-invent the wheel every time we or
someone else does something like this. And maybe it's 20 pages because it
went through a cycle of peer review at the IETF that addressed hopefully
most of the issues and edge cases that we would probably painfully
recapitulate, one at a time, over the next year if we did just try another
one-off. Seems like the cost of a few extra characters is small in
comparison.
On Mon, Mar 24, 2014 at 8:03 PM, Trevor Perrin <trevp@trevp.net> wrote:
> On Mon, Mar 24, 2014 at 7:11 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
> > Hi Trevor
> >
> >> 1) Why does the content-type need to be specified in the link? Why
> >> not just include it as input to the hash?
> >
> > I believe this is because the existing RFC already uses the syntax.
> > See http://tools.ietf.org/html/rfc6920#section-3.1
>
>
> Hi Devdatta,
>
> What does the RFC 6920 format give you compared to a simple
> algo-specific attribute like sha256="base64...", and then hashing the
> content-type followed by a separator char (";") prior to the data?
>
> The 6920 format adds verbosity, parsing, and having to read a 20-page
> (?!) doc. What's the benefit?
>
>
> Trevor
>
>
Received on Tuesday, 25 March 2014 04:28:27 UTC