Re: [Uri-review] Fwd: [IANA #1239721] Drop scheme permenant registration

[Graham Klyne <[e-mail]>]

Hi Tim, all,

(These comments are made in a personal role, and are not part of my response as 
designated reviewer for IANA registrations.)

Now that we have resolved the syntax issue, there is a possibility for more 
meaningful discussion of the proposed scheme itself.

There's a general discussion to be had about (a) whether there is significant 
support for permanent registration of this scheme, and (b) the form in which the 
scheme specification needs to be published if there is such support.

Regarding (a), it's hard to make progress without a clear and shared 
understanding of what the scheme is for.  See further comments below.

Regarding (b), I think the current form of specification publication at [1] is 
inadequate for a permanent scheme registration.  The ideal here would be an 
IETF-stream RFC, which has been subjected to IETF last-call review procedures. 
Or equivalent publication by another recognised open standards body (such as 
W3C, etc.).   These routes involve enough review to demonstrate support.  Other 
ways are possible in principle, but every permanent URI registration to date has 
been published as an IETF RFC, so I'd expect it to be more challenging to 
achieve permanent registration by another route.  If a proposed scheme has been 
widely implemented, and there is a public specification that those 
implementations follow, that might be another path.

[1] https://sro.dropnumber.com/

Is there any implementation of this proposed scheme?  If there were, I would 
imagine the specification to be far more specific than what is described.  I 
don't think there is sufficient information in the supplied document to create 
independent interoperable implementations, so I think there's a fair amount of 
additional work needed.

In your case, assuming you want to proceed with the work this will entail, I 
would suggest publishing as an Internet Draft for review purposes, with the 
intent of publication as an IETF RFC if it passes the review process.



Concerning the specification itself:

I refer to the specification at [1], as of 2022-09-24.



1.  What problem does the scheme attempt to solve?

The introduction says "This scheme shortens the path to further unifying
communications by using public mechanisms of continuity for the pre-
resolution of private and public service integration.", but I have no idea what 
that means in practice.

Looking ahead, I can make a guess as to what you are trying to achieve, but I 
couldn't say with any confidence.  Let me try, and you can tell me if I'm right:

"The 'drop' scheme is used in conjunction with DDDS [RFC3401] resolution 
mechanisms in order to find alternative communication channel locators for an 
entity associated with a given telephone number.  As such, it uses a telephone 
number to identify an entity (e.g., a person, organization or machine), and 
associates a lookup mechanism to find communication endpoints for contacting 
that body."

I can imagine an example of this being to use a fax telephone number to find an 
Internet fax [RFC2305] email address.

If I'm right about the intent, this begs a number of new questions, but I won't 
explore that space until I understand what it is the scheme is intended to achieve.



2. Syntactic compatibility

It's not necessary (and is quite distracting for review purposes) to repeat text 
verbatim from RFC 3986.  The important thing here is to define a syntax for the 
scheme-specific-part associated with the proposed scheme.  I'm not seeing that 
in your document.  ("It would look similar to 'sd54g54.dropexample.com'" is not 
an adequate syntax specification.)



3. Definitions and Operations

I think the text here is confusing "resolution" and "retrieval" [2].  But it's 
hard to be sure without a clear statement of purpose (see 1 above).

[2] https://datatracker.ietf.org/doc/html/rfc3986#section-1.2.2

What does a 'drop:' URI identify?  What interactions are possible with the 
identified resource?  If the interactions include retrieval, what kind of 
representations would be returned?

You mention use of DDDS [RFC3401].  In my view, that would constitute a 
resolution mechanism, the result of which would be a URL or some other address 
that could be used to initiate an interaction with the identified resource.  But 
DDDS is a framework, not a fully-fledged mechanism:  it still needs matching 
patterns and replacement strings in order to perform the resolution process. 
There is no indication of what these are, or how they may be defined.

I think the paragraph "Permanency of what is identified by the 
scheme-specific-part is not guaranteed and is user specific...." belongs in the 
statement of purpose (I read that as a rationale for requesting a new scheme 
rather than a urn namespace.)  The latter part of this paragraph doesn't serve 
any useful purpose that I can see.



4. Internationalization and Character Encoding

This doesn't make any sense to me.  I don't think it adequately addresses I18N 
issues here.

If you need to allow non-ASCII characters, then you're talking about an IRI, and 
a mention of the correspondence between IRI and URI forms should be given (see 
https://www.rfc-editor.org/rfc/rfc7595#section-1.1).



I hope this helps you to plot a path ahead,

#g








On 20/09/2022 01:52, Timothy Mcsweeney wrote:
> I changed my spec to use the colon and attempted to register it as permanent.  This is the response below.  Personally, I thought when the list reviewed the original everything was already considered.  Is there anything the list would like to add orcomment on?
> 
> 
>> ---------- Original Message ----------
>> From: Sabrina Tanamal via RT <[e-mail]>
>> To: [e-mail]
>> Date: 09/19/2022 5:08 PM EDT
>> Subject: [IANA #1239721] Drop scheme permenant registration
>>
>>   
>> Hi Tim,
>>
>> Please see responses from Graham Klyne below.
>>
>> Thanks,
>> Sabrina
>>
>> =====
>>
>> I think this proposal is not yet ready for permanent registration. My
>> recommendation is that the current "provisional" registration status should
>> stand, updated with other details from this new request, until the scheme
>> specification reaches IETF standard status, or a comparable level of community
>> consensus and support.
>>
>>
>> RFC 7595 [2] states
>>
>> "'Permanent' status is appropriate for, but not limited to, use in standards.
>> For URI schemes defined or normatively referenced by IETF Standards Track
>> documents, 'permanent' registration status is REQUIRED."
>>
>> So, while IETF standard status of the defining document is not an absolute
>> requirement, a comparable level of review and community consensus is expected
>> (as the resulting specification may subsequently be incorporated by reference
>> into IETF standard specifications).
>>
>> As an immediate action, I would say that the revised draft [1] should be
>> resubmitted to the URI-review list for further review. The discussion to date
>> (that I am aware of) has not progressed beyond the syntactic compatibility issue
>> (which was clearly a blocker to any further progress). It is good that this has
>> been tackled in the revised draft, and I would now expect to see wider review of
>> URI requirements conformance, and other aspects of the proposed scheme.
>>
>> One way to demonstrate community consensus for permanent registration would be
>> to develop the specification as an IETF-track RFC, subject to an IETF last-call.
>> (I note that, to date, all permanent URI schemes registered are defined in
>> IETF RFC documents.)
>>
>>
>> Some areas that I would expect to see discussed and tested by community review:
>>
>> - On "Demonstrable, New, Long-Lived Utility" the document reads rather as a
>> philosophical treatise. What is called-for here is a clear statement of (a)
>> what problem is being addressed, (b) why it is not addressed by existing
>> specifications, (c) evidence that there is sufficient community of interest to
>> actually make it happen as an internet standard, and (d) that the specification
>> is robust and stable enough to survive inevitable changes in the Internet and
>> WWW. The document mentions using 'drop': URIs in a browser address bar, but is
>> there any indication of any level of support from browser implementers?
>>
>> - On syntactic compatibility, the provided document says: "Characters of the
>> scheme-specific-part have not been limited." This is unclear - RFC3986 limits
>> characters that may appear here - is this an attempt to dis-apply the RCFC3986
>> requirement? Assuming not, this should be stated more clearly. More generally,
>> I'd expect some other eyeballs to conform that the proposed scheme conforms
>> fully to RFC3986 syntax.
>>
>> - specification document: it is not clear to me that the documentation provided
>> is adequate for creation of independent interoperable implementations (the usual
>> touchstone for an IETF standard). There are vague references to DDDS (RFC3401),
>> which, if I recall correctly, requires additional details (such as regex and
>> substitution strings) to be applicable in any particular situation. There is
>> also vague discussion in the document provided that talks about use of DNS
>> records, which I think probably duplicates material in the DDDS specification,
>> which could be a source of ambiguity and confusion for implementations.
>>
>> - I think the section on "Internationalization and Character Encoding" needs to
>> be clearer, and subject to fuller review by I18N experts in the wider community.
>> I'm concerned about "Queries that come in non-ASCII encoding must be allowed
>> to go forward so that private resolution can continue if A and SRV record
>> lookups fail." I'm not understanding how this is a valid part of a URI scheme
>> specification (it might be applicable to the specification of a private
>> resolution implementation, but that would be a separate issue). More useful
>> here might be a discussion of transformation between 'drop:' URIs and IRIs.
>>
>> The above 4 bullet points are not topics to be discussed as part of the scheme
>> registration process. I'm mentioning them here as a possible indication of some
>> areas where I'd expect community review to test and quality assure the
>> specification.
>>
>> =====
>>
> 
> [1] https://sro.dropnumber.com/#section-3
> 
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review

-- 
Graham Klyne
mailto:[e-mail]
http://www.ninebynine.org
Skype/Twitter: @gklyne