Re: [Uri-review] Initial inquiry into URI proposal (nym)

[DataPacRat <[e-mail]>]

On Thu, Jun 27, 2013 at 7:12 AM, Graham Klyne <[e-mail]> wrote:
> (For some unknown reason, my email client stopped showing me emails to this
> list, so I'm late responding to this thread.)

(No worries.)


> You may have identified problem that needs solving (I'm not judging that),
> but I'm not seeing why the solution is another URI scheme.   A key question,
> for me, is an explanation of "what does a nym: URI actually *identify*",
> which I'm not seeing on a quick scan of the materials.  Once that's clear,
> it's possible to ask questions about whether a new URI scheme is needed or
> appropriate.

A metaphor:

A http: URL is like a finger pointing to a painting, or a finger
pointing to a poem. A nym: URI is a pair of fingers, one pointing to a
finger pointing to a painting of the moon, the other pointing to a
finger pointing to a poem about the moon, and announces that they are
both art about the same moon, even if the painting and poem don't look
anything like each other.


Another attempt: Having just skimmed RFC 2396, section 1.1 of that
mentions that a 'resource' doesn't itself have to be network
retrievable, and can include humans or corporations. If it helps, it's
probably safe to assume that the resources intended to be referred to
by nym: are people. (Though with something approaching the current
proposal, nym: is general enough to refer to just about anything else,
such as a moon.)


> You say in your proposal:
>> "The ‘nym’ URI announces that a
>> given authority asserts that two or more representations both refer,
>> at least in a general sense, to the same thing; that is, they describe
>> the same entity in different formats."
> But this is not what URIs do:  they
> *identify* things (sometimes by location), they don't "announce assertions".

The profile at twitter.com/DataPacRat refers to a particular page on a
particular website; the profile at facebook/com/DataPacRat refers to
an entirely different page on an entirely different website. What I'm
trying (poorly) to do is to have nym: identify the person described by
that twitter page, and by that facebook page, and to point out that
both of those persons are the same person.

Perhaps the current draft of nym: could be improved by making not just
the third, fourth, and further referenced URIs optional, but making
the second one optional as well, allowing a nym: URI to contain just a
single reference; in which case the nym: would be a simple
second-order pointer to whatever that reference is referring to. It
seems likely that a single-reference nym: wouldn't have any purpose to
the level-of-confidence field, authentication hash, or even authority;
but given how much trouble I've been having expressing the basic idea
behind nym:, it might at least be valuable as an introduction to an
indirect reference, if nothing else.


> If you really want to use a URI to convey this kind of assertion, you could
> adopt or design an assertion language and corresponding MIME type, and then
> wrap the whole thing in a data: URI.

Now this is an interesting thought. Not sure yet whether or not it's a
better solution than a URI, but it's certainly worth considering.

After a quick check of MIME types, I've confirmed that there's already
one containing almost everything which a text/nym MIME type would:
text/vcard (RFC 6350). It seems fairly likely that given the amount of
overlap, a proposal for an independent text/nym would be redirected
into a suggestion to simply add a few fields to extend the existing
text/vcard to include the fields nym requires (asserting authority,
dates, confidence-level, authentication hash). Which, quite possibly,
would simply be rejected on the basis that vcard has an entirely
different purpose; leaving the overall certificate-authentication
problem unsolved.

Another possible issue is that a vcard+nym format seems likely to be
limited in spread to roughly the current spread of plain-vcard; which,
even though I have a QR code on my own calling card pointing to a vcf
file, isn't all that widespread.

As far as I can tell, the vcard format was handed to the 'Internet
Mail Consortium' around twenty years ago - which itself closed down at
least ten years ago, leaving just its website for reference purposes.
So I'm not sure what group I would need to get in touch with in order
to even discuss the option - well, that is, short of simply taking it
upon myself to write an updated spec, which seems a bit more arrogant
than working through the established URI proposal process.


This compares to writing up nym: as a URI of second-order referencing,
which, once the bugs are hashed out (which would need to be done
anyway), seems easy enough to get an Internet Draft created; at which
time I can start, for example, getting in touch with the programmers
of software containing contacts to try to persuade them to include
nym:-based functionality, and start hunting down someone in the
CA/Browser Forum or CA Security Council to offer a Bayesian-based
alternative.


So, so far, as far as I can tell, working towards nym: as a URI offers
more paths, fewer blocks, and a greater chance of success of fixing
the identity-verification problem than working towards a text/nym MIME
type. But the latter is still worth keeping in mind as a backup plan
in case something blocks the former approach. (But, as always, I'm
open to being persuaded to change my mind.)


Thank you for your time,
--
DataPacRat
"No man spreads a lie with so good grace as he that believes it." --
John Arbuthnot