On Wed, Dec 05, 2001 at 03:58:08PM -0800, hal(_at_)finney(_dot_)org wrote:
David Shaw writes:
As I see it (and this departs from the language in the draft), being
human readable shouldn't necessarily mean that the data cannot also be
machine readable.
To use the URL example, if there was a "myhomepage(_at_)akamai(_dot_)com"
name
(to use the proper user name space from the draft), and that was
defined as a URL for my home page, I don't see any particular reason
why a machine shouldn't process such data - the processing function
would be keyed off of the "name" value, so the program would have a
pretty good notion of what was going to be present in the "value"
field.
Instead, I would handle this by not setting the human-readable flag, and
instead choose a name for the notation which tells the machine that it
is a URL. Then the software can know that URLs can be safely displayed
to a human. Leaving the human-readable flag clear allows the software
to read and try to understand the notation. Nothing prevents it from
displaying it to a human if the semantics of that notation imply that
it would be reasonable.
Yes, that would work as well. Still, I think that allowing the
implementation to look at human-readable notations is more flexible in
that a new notation tag can be at least partially supported without
code changes.
If human-readable meant printf()-able, then the code could just
display anything that had the human-readable flag set so at least the
user could see the notation and thus have partial support for the new
tag. The software implementation could not handle the notation
without a upgrade, but I suspect that while automation is nice, many
notations could be handled by a user as well (for example: "This key
is revoked, please use key 0xXXXXXXXXXX instead").
David
--
David Shaw | Technical Lead
<dshaw(_at_)akamai(_dot_)com> | Enterprise Content Delivery
617-250-3028 | Akamai Technologies