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

[Graham Klyne <[e-mail]>]

On 27/06/2013 17:43, DataPacRat wrote:
>> 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.
>

OK, to continue the metaphor, a URI is just a finger, not a hand with more than 
one finger.  If you want to create a stucture that embodies a "pair of fingers", 
that seems to me beyond the scope of what a URI is intended to do.

>
> 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.)

To be clear, I'm making no assumptions about network retrievability.

You seem to be saying that a nym: URI identifies a person, or maybe anything.  I 
feel there's a slight lack of clarity of purpose here.  For example, a common 
practice on the Web is to mint an http: URI to refer to something, and create a 
web resource containing a description of the thing referenced.  This is not 
without its difficulties and controversies, but there are some practices around 
this that can be adopted to avoid most of the bear-traps.  This doesn't need any 
new URI schemes.

What I'm working towards here is: why a new URI scheme?  What are the 
*identifying* semantics of this scheme that differ from all the other URI schemes?

>
>> 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.

So you're trying to make a URI that (a) identifies things known by two different 
names, and (b) asserts that they are naming the same thing.  This is a common 
enough requirement, but I've never seen anyone try to do it with a URI scheme.

I can only repeat my earlier claim that this is not what URIs are designed to 
do.  I think there are many better ways to address this problem than trying to 
shoehorn a whole new load of semantics into a URI scheme. (I'm not dismissing 
your goal, just suggesting that, as far as I can tell, you're trying to solve it 
with the wrong tool.)

>
> 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.

I don't think that helps.  From my perspective, we're falling at the first 
hurdle and such details aren't really helpful or relevant.  The second, and 
further identifiers can be combined by some structure that is not part of any 
URI scheme.  This would possibly be a much more general solution to the problem 
you're addressing, as you'd be able to use the full range of existing URI 
schemes to identify the things you want to assert are the same.

>
>> 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.
>

At what appears to be an early stage of developing the ideas, I'd suggest 
defining a new format that may inherit some properties from an existing format. 
  That would be a relatively low-pain route for developing and exemplifying your 
ideas.  Whether such extensions might eventually become part of an existing 
format, I can't say.  But it seems a better bet to me than trying to stretch the 
very function of a URI in the way you seem to be attempting.

>
> 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.
>

You lost me there.  What is a "a URI of second-order referencing"?  If it's 
important, this is something that needs to be clarified, separately from all the 
issues of assertions and confidence.  It maybe that there's already some 
structure that achieves what you are trying to do, but without clear 
understanding, I can't tell.

>
> 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.)

Don't bet on the "fewer blocks".  The bar for general acceptance of new URI 
schemes is rather high compared with many of the alternatives, especially new 
data formats/content types.

#g
--