Re: [Uri-review] Request for review

[Timothy Mcsweeney <[e-mail]>]

text version:
Just putting this conversation up here to show that Ted brought up some good points that I have fixed in the second draft.


> On 05/27/2020 7:42 PM Timothy Mcsweeney <[e-mail]> wrote:
> 
> 
> Just putting this conversation up here to show that Ted brought up some good points that I have fixed in the second draft.
> > On May 21, 2020 at 7:18 PM Timothy Mcsweeney <[e-mail]> wrote: 
> > 
> > 
> > Hi Ted,
> > I have a question for you. In your last couple emails when you said the words "permanent identifier", did you mean:
> > 
> > the string always matches the same object forever
> > -or-
> > the string will always be an identifier for these particular types of objects
> > -or-
> > the string is disposable and there will never be another string like it again.
> > 
> > Thanks,
> > Tim
> > > On May 20, 2020 at 6:42 PM Ted Hardie < [e-mail]> wrote:
> > > 
> > > 
> > > On Tue, May 19, 2020 at 6:32 PM Timothy Mcsweeney < [e-mail]> wrote:
> > > >
> > > > Ted,
> > > > Thank you very much for the feedback. Would I be correct in deducing from your reply that if the 'drop' scheme remained a locator that you would recommend it remain a URI over a URN?
> > > > Tim
> > > 
> > > Because you can use the DDDS to get from a URN to the a retrieval
> > > step, I'm not sure that's the critical property for me. I think for
> > > me the difference is whether the drop-string is unique or not. As an
> > > example, a URN with a NBN
> > > ( https://en.wikipedia.org/wiki/National_Bibliography_Number) can go
> > > through a resolver to identify a specific resource. In cases like
> > > NBNs (or RFC numbers, for which there are also URNs), the number is
> > > never reassigned; the issuer guarantees that the NBN will change if
> > > the resource changes.
> > > 
> > > If you are constructing an identifier that is unique but will have
> > > internal references which change (e.g. if the telephone number or
> > > address associated with it change), you can still use a URN, but it
> > > will be associated will be a meta-identifier for the collection of
> > > changing versions. That's how vCard's CLIENTPIDMAP works, for
> > > example. It sort-of sounds like drop-strings would be dereferenable
> > > versions of this, via something like
> > > CLIENTPIDMAP.well-known-domain.example. The usefulness of that gets
> > > back to the question we discussed before,of whether these are mnemonic
> > > or not; discovering the right drop-string to use becomes a major part
> > > of the exercise.
> > > 
> > > In general, I think the vCard case might be a useful one for you to
> > > spend some time with, because it may be easier to communicate what
> > > drop-string will do if you relate it to an existing case.
> > > 
> > > regards,
> > > 
> > > Ted Hardie
> > > 
> > > 
> > > >
> > > > Hi Tim,
> > > > On Tue, May 19, 2020 at 3:40 PM Timothy Mcsweeney < [e-mail]> wrote:
> > > > Hi Ted,
> > > > Thank you for taking the time to have a look at the draft. I had not considered the use of more than one domain. I will be sure to clarify that there will only be one second level domain used for http. Because I am limited to four flags in the DDDS, at this time I would say my intent would be the same as listed. You are probably right when saying that section will need a rewrite.
> > > > Your statement about the drop-string functioning as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource is spot on but in my head it is a locator. I'm going to give that some more thought. Generally speaking, is this draft something that you would personally find appealing to use?
> > > > If this intended to be a permanent identifier and you intend to use the DDDS, I would suggest you consider either a URN or, if you want to look outside the IETF, at an implementation of the handle system, which is currently maintained by the DONA foundation. If you stick with a URN, the result would be a string like this:
> > > > urn:drop:nss-specific-string
> > > > Drop is the namespace identifier (NID) in this case. The issuer assigned that NID is the issuer of names-specific-strings and has to maintain certain guarantees related to uniqueness, which may or may not work for you depending on your application model. There is, however, already a specification for how to use the DDDS to retrieve URNs (RFC 3402) as well as some experience with S-NAPTR (RFC 3958), which may simplify your deployment.
> > > > Your question about whether or not I feel this would be appealing to use is a little hard to answer without knowing more about the construction of the resources it returns and the creation of the strings. If they are essentially random, the deployment model is hard to get going because the users are trading a series of mnemonic strings for an opaque one. vCards (RFC 6350), for example, can contain a UUID in URN form; this is unique, but not memorable. Systems can use it to confirm that a vCard is a new entry in a contacts database, but the URN UUIDs do not really replace any of the entries in the vCard in other contexts. If the strings are not random, then you get markets in the names, along with risks of squatting and so on. Even for the opaque strings there have been such markets (sales of mnemonic telephone numbers, for example, where either keypad mapping or repeating numbers are valued as easy to remember). Those markets (for domain names, twitter handles, and so on) ten
 d to produce a lot of work in balancing the needs of those trying to maintain trademarks and those wishing to create new marks and identifiers.
> > > > regards,
> > > > Ted Hardie
> > > >
> > > > Sincerely,
> > > > Tim
> > > > On May 19, 2020 at 11:45 AM Ted Hardie < [e-mail]> wrote:
> > > > Hi Tim,
> > > > Thanks for the pointer to the draft. I think there are two issues here which are large enough that you may wish to think about the implied architecture. The first is a syntactic issue: the use of "#" as the only delimiter in the proposed URIs. As RFC 3986 describes it, the "#" delimiter is used for identifying fragments and is thus dependent on the MIME type of the retrieved object:
> > > > The fragment's format and resolution is therefore
> > > > dependent on the media type [RFC2046] of a potentially retrieved
> > > > representation, even though such a retrieval is only performed if the
> > > > URI is dereferenced.
> > > > This does not appear to match your usage. The usage you appear to be seeking is a transposition of the string to a subdomain of a well-known domain, so that a client can attempt retrieval via the three methods you enumerate; it is not clear from the document whether there will ever be more than one permitted domain here. A simpler implementation would appear to be drop:drop-string.well-known-domain.example.
> > > > Second, your document appears to imply that the drop string is used to augment existing telephone numbers and addresses, but it is not terribly clear how it does this. One interpretation might be that the drop-string functions as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource. This section:
> > > > Primarily functioning as a locator there are three ways to get to a
> > > > 'drop' URI resource, http, srv records, and private resolution for
> > > > anything not found using the previous two methods. The first, or
> > > > default, action is when an application invokes the 'drop' URI it will
> > > > cause a lookup for matching application information starting with an A
> > > > record [RFC1035], then on to Service records [RFC2782], and then on to
> > > > other available records that may offer a new rule set for resolution.
> > > > raises a problem with this approach: the records returned by SRV are fundamentally different, in that they are onward pointers to other domains and resolutions. If the implication is that HTTP is always used to retrieve drop records and the appropriate server is discovered by either using an A record, an SRV record, or private resolution, then this section needs a major re-write (to include AAAA records and to clarify the intent). It's also not clear what long lived utility a new scheme serves here if the result is always https://some-string.discovered-domain.example/ .
> > > > If there were a different guarantee of uniqueness than the DNS, this would seem closer to a URN than other URI forms, or possibly an implementation of the handle system (as DOIs are). There is, unfortunately, not enough detail in the draft on the overall system to be confident of that.
> > > > regards,
> > > > Ted Hardie
> > > >
> > > > On Mon, May 18, 2020 at 6:21 PM Timothy Mcsweeney < [e-mail]> wrote:
> > > > Hello everyone,
> > > > This is a request for a review of the 'drop' URI scheme. The draft can be found here < " rel="noopener" target="_blank" data-mce-href="https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>">https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/> (https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/). Thank you.
> > > > Sincerely,
> > > > Tim McSweeney
> > > > _______________________________________________
> > > > Uri-review mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/uri-review
> > > >
> > > >
> > > >
> > > >
> > > >
> 
>