[Uri-review] mvrp: and mvrps: proposal (was: [IANA #1352813] Request for Assignment (uri-schemes))

[Graham Klyne <[e-mail]>]

Hi Antonio, thank you for submitting your proposal for review.

(For clarity: I'm responding here in a personal capacity; this isn't a formal 
response to your request.)

I believe there is much work to do before this will be ready for permanent 
registration.  A new permanent URI scheme is expected to facilitate 
interoperability between independent applications in much the same way as any 
Internet standard.

I cannot see in your referenced document anything that looks like a URI 
specification, so it's not really clear what it is that you seek to register for 
the mvrp and mvrps schemes.  I would expect there to be a URI description that 
allows  interoperable implementations by independent applications using such a 
scheme, at least to the extent of identifying a resource, and usually to the 
extent of allowing them to initiate an interaction with it.

It's also not clear to me what kind interoperability your proposal would 
achieve: your documentation appears to be specific to Muvor applications, 
services and devices and it's not clear to me that this is a public 
interoperable specification -- I could be wrong about that, and if I am it would 
help for the intended interoperability to be exposed more clearly.


My feeling is that, if you feel that your proposal matches the requirements in 
RFC7595 (see below), a way to proceed would be to write a separate stand-alone 
document describing those aspects, making reference to (rather than replicating) 
your existing specification document as appropriate.  Unless you are working 
with some other recognized open standards organization, a preferable format for 
such a document would be as an IETF RFC.  In any case, we would be needing a 
stable, publicly accessible reference that is acceptable to be referenced by an 
IETF standard [1].

[1] https://www.rfc-editor.org/rfc/rfc2026.html#section-7


My further comments will be with reference to RFC 7595 [2] and RFC 3986 [3], 
pointing out the kind of detail that I think needs to be covered in the 
specification of a permanent URI scheme.

[2] https://www.rfc-editor.org/rfc/rfc7595

[3] https://www.rfc-editor.org/rfc/rfc3986

What follows is my round-up of what I think is needed for this proposal to be 
considered for permanent registration; there may be other considerations that I 
haven't thought of:


1. Purpose

"A Uniform Resource Identifier (URI) is a compact sequence of characters that 
identifies an abstract or physical resource."
-- RFC3986 [3]

What are the "abstract or physical resource"s identified by this proposal?  How 
does an application go about initiating an interaction with such a resource 
(it's generally OK to reference separate protocol specifications for this part)?


2. Demonstrable, New, Long-Lived Utility

"New schemes ought to have utility to the Internet community beyond that 
available with already registered schemes.  The scheme specification SHOULD 
discuss the utility of the scheme being registered"
-- RFC7595, section 3.1 [2]

This requires the existence of a URI scheme specification, which I don't see.

This requirement also touches on a related consideration: why does this proposal 
need to be a URI scheme at all?  To my mind, being a URI scheme implies that it 
can be used in some context where any other URI scheme might be valid (and hence 
the new scheme name distinguishes a particular new use case).  Are there any 
contexts where an mvrp/mvrps URI scheme would appear where some other URI might 
also be used?  If not, then I'd suggest that this isn't really a URI, just a 
string that happens to look like a URI.


3. Why two scheme names?

I note that the world wide web architecture document recommends against 
associating multiple URIs the same resource [4].

[4] https://www.w3.org/TR/webarch/#uri-aliases

(Historically, there was a tendency to treat secure and insecure protocols as 
accessing different resources -- such as http and https -- but more recently 
this has been found to cause complications for some web applications, especially 
with the move from http to https-everywhere.  Web architecture works better when 
the URI-scheme doesn't convey more detail than needed about the access 
mechanisms, and today we see that https URIs can be used with quite different 
underlying protocols in a way that is largely transparent to applications -- cf. 
HTTP/1.1, HTTP/2 [5], HTTP/3[6]).

[5] https://www.rfc-editor.org/rfc/rfc9113.html

[6] https://www.rfc-editor.org/rfc/rfc9114.html


3. Syntactic Compatibility

"All scheme specifications MUST define their own URI <scheme-specific-part> syntax"
-- RFC7595, section 3.2 [2]

I cannot  find any scheme syntax specification in your proposal, which would be 
needed to verify this requirement.


4. Well Defined

"... a scheme definition itself MUST be clear as to how it is expected to function"
-- RFC7595, section 3.3 [2]


5. Definition of Operations

"As part of the definition of how a URI identifies a resource, a scheme 
definition SHOULD define the applicable set of operations that can be performed 
on a resource using the URI as its identifier."*
*-- RFC7595, section 3.4 [2]


6. Security and Privacy considerations

"Definitions of schemes MUST be accompanied by a clear analysis of the security 
and privacy implications for systems that use the scheme"
*
*-- RFC7595, section 3.7 [2]

If I'm understanding the intent of the proposal, this is an area that needs to 
be especially carefully worked out, and widely reviewed, if interactions are not 
going to expose users to open-ended security vulnerabilities.

To this end, I think such analysis must cover not only the chosen cryptography 
(which your proposal discusses to some extent), but also the protocols and 
systems within which such cryptography is embedded (which I'm not seeing).


7. Further considerations

RFC7595 (sections 3.5 to3.9) [2] details some further considerations that may or 
may not be relevant.  It is helpful if a specification mentions these 
considerations so that reviewers can see that they have been considered.


#g


On 24/01/2024 18:11, Wakuu Corps wrote:
> Greetings,
>
> Please receive and review my application for a URI Scheme.
>
> Below is the fulfilled template from Section 7.4 of RFC 7595 in compliance 
> with Section 7.2 of RFC 7595 for both schemes:
> Scheme name: mvrp
>    Status: Permanent
> Applications/protocols that use this scheme name:
> Muvor.com, Secure Muvor Protocol, Muvor Virtual Machine, Muvor APIs, Muvor 
> SDK, subsequent derivatives, Muvor Protocol (on-chain) Websites, Muvor 
> Devices, Muvor OS, Muvor AI, Test Network connections, and more.
>    Contact: Antonio Walker - 128 Hamilton St, Wellington, OH, 44090
>     phone: [phone] email(s): [e-mail]; [e-mail];
>    Change controller: Antonio Walker OHIO TC216945
>    References:
>        Walker, Antonio. “Universal Business Consensus - Wakuuenterprises.Com.”
> /       Muvor - Universal Business Consensus/, Wakuu Enterprises, Inc., 5 Nov. 
> 2020,
> wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-1.pdf 
> <http://wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-1.pdf>.
>     Scheme name: mvrps
>     Status: Permanent
>     Applications/protocols that use this scheme name:
>          Muvor.com, Muvor Protocol w/ TLS, Muvor Virtual Machine, Muvor APIs,
>          Muvor SDK, subsequent derivatives, Muvor Protocol (on-chain) Websites,
>          Muvor Devices, Muvor OS, Muvor AI, Main Network connections, and more.
>    Contact: Antonio Walker - 128 Hamilton St, Wellington, OH, 44090
>      phone: [phone] email(s): [e-mail]; [e-mail];
>    Change controller: Antonio Walker OHIO TC216945
>    References:
>        Walker, Antonio. “Universal Business Consensus - Wakuuenterprises.Com.”
> /       Muvor - Universal Business Consensus/, Wakuu Enterprises, Inc., 5 Nov. 
> 2020,
> wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-1.pdf 
> <http://wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-1.pdf>.
>
> Please advise for further information, or any questions.
>
> Best Regards,
>
> Antonio Walker
> Wakuu Enterprises, Inc. <http://wakuuenterprises.com/>
> Newport Beach, CA 92663
> 213-477-0111
>
>
> On Wed, Jan 24, 2024 at 12:49 PM David Dong via RT <[e-mail]> 
> wrote:
>
>     Hi Tony,
>
>     The links provided do not seem to be working; we appear to be getting a
>     HTTP Not Found error.
>
>     Also, please note that permanent registration requests, you will need send
>     the proposed registration to the [e-mail] (and any other
>     applicable) mailing list for public review for about a four-week period,
>     before requesting for the registrations. Please see Section 7.2 of RFC
>     7595 for instructions:
>
>     https://www.rfc-editor.org/rfc/rfc7595.html#section-7.2
>
>     Provisional registrations would not need this review.
>
>     Please let us know how you would like to proceed.
>
>     Best regards,
>
>     David Dong
>     IANA Services Sr. Specialist
>
>     On Wed Jan 24 00:36:47 2024, david.dong wrote:
>     > Hi Tony,
>     >
>     > We've sent this to the expert for review.
>     >
>     > I will follow up again when we hear back.
>     >
>     > Best regards,
>     >
>     > David Dong
>     > IANA Services Sr. Specialist
>     >
>     > On Wed Jan 24 00:18:43 2024, [e-mail] wrote:
>     > > Hello David,
>     > >
>     > > Here is the fulfilled provisional template in Section 7.4 of RFC 7595
>     > > for
>     > > both schemes:
>     > >      Scheme name: mvrp
>     > >    Status: Provisional
>     > >    Applications/protocols that use this scheme name:
>     > > Muvor.com, Secure Muvor Protocol, Muvor Virtual Machine, Muvor APIs,
>     > > Muvor
>     > > SDK, subsequent derivatives, Muvor Protocol (on-chain) Websites, Muvor
>     > > Devices, Muvor OS, Muvor AI, Test Network connections, and more.
>     > >    Contact: Antonio Walker - 128 Hamilton St, Wellington, OH, 44090
>     > >     phone: [phone] email(s): [e-mail];
>     > > [e-mail];
>     > >    Change controller: Antonio Walker OHIO TC216945
>     > >    References:
>     > >        Walker, Antonio. “Universal Business Consensus -
>     > > Wakuuenterprises.Com.”
>     > > *       Muvor - Universal Business Consensus*, Wakuu Enterprises,
>     > > Inc., 5
>     > > Nov. 2020,
>     > > wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-
>     <http://wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp->
>     > > v1.1.pdf.
>     > >
>     > >
>     > > Scheme name: mvrps
>     > > Status: Provisional
>     > > Applications/protocols that use this scheme name:
>     > >      Muvor.com, Muvor Protocol w/ TLS, Muvor Virtual Machine, Muvor
>     > > APIs,
>     > >      Muvor SDK, subsequent derivatives, Muvor Protocol (on-chain)
>     > > Websites,
>     > >      Muvor Devices, Muvor OS, Muvor AI, Main Network connections,
>     > > and more.
>     > >
>     > > Contact: Antonio Walker - 128 Hamilton St, Wellington, OH, 44090
>     > >   phone: [phone] email(s): [e-mail];
>     > > [e-mail];
>     > > Change controller: Antonio Walker OHIO TC216945
>     > > References:
>     > >     Walker, Antonio. “Universal Business Consensus -
>     > > Wakuuenterprises.Com.”
>     > > *       Muvor - Universal Business Consensus*, Wakuu Enterprises,
>     > > Inc., 5
>     > > Nov. 2020,
>     > > wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-v1.1.pdf
>     <http://wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-v1.1.pdf>.
>     > >
>     > > Thanks again!
>     > >
>     > > Best Regards,
>     > >
>     > > Wakuu Enterprises, Inc. <http://wakuuenterprises.com/>
>     > > Newport Beach, CA 92663
>     > > 949-876-3474
>     > >
>     > >
>     > > On Tue, Jan 23, 2024 at 7:13 PM Wakuu Corps <[e-mail]>
>     > > wrote:
>     > >
>     > > > Whoops, my apologies.
>     > > >
>     > > > Here is the fulfilled template in Section 7.4 of RFC 7595 for both
>     > > > schemes:
>     > > >      Scheme name: mvrp
>     > > >    Status: Permanent
>     > > >    Applications/protocols that use this scheme name:
>     > > > Muvor.com, Secure Muvor Protocol, Muvor Virtual Machine, Muvor APIs,
>     > > > Muvor
>     > > > SDK, subsequent derivatives, Muvor Protocol (on-chain) Websites,
>     > > > Muvor
>     > > > Devices, Muvor OS, Muvor AI, Test Network connections, and more.
>     > > >    Contact: Antonio Walker - 128 Hamilton St, Wellington, OH, 44090
>     > > >     phone: [phone] email(s): [e-mail];
>     > > > [e-mail]
>     > > > ;
>     > > >    Change controller: Antonio Walker OHIO TC216945
>     > > >    References:
>     > > >        Walker, Antonio. “Universal Business Consensus -
>     > > > Wakuuenterprises.Com.”
>     > > > *       Muvor - Universal Business Consensus*, Wakuu Enterprises,
>     > > > Inc., 5
>     > > > Nov. 2020,
>     > > > wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-
>     <http://wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp->
>     > > > v1.1.pdf.
>     > > >
>     > > >
>     > > > Scheme name: mvrps
>     > > > Status: Permanent
>     > > > Applications/protocols that use this scheme name:
>     > > >      Muvor.com, Muvor Protocol w/ TLS, Muvor Virtual Machine, Muvor
>     > > > APIs,
>     > > >      Muvor SDK, subsequent derivatives, Muvor Protocol (on-chain)
>     > > > Websites,
>     > > >      Muvor Devices, Muvor OS, Muvor AI, Main Network connections, and
>     > > > more.
>     > > >
>     > > > Contact: Antonio Walker - 128 Hamilton St, Wellington, OH, 44090
>     > > >   phone: [phone] email(s): [e-mail];
>     > > > [e-mail];
>     > > > Change controller: Antonio Walker OHIO TC216945
>     > > > References:
>     > > >     Walker, Antonio. “Universal Business Consensus -
>     > > > Wakuuenterprises.Com.”
>     > > > *       Muvor - Universal Business Consensus*, Wakuu Enterprises,
>     > > > Inc., 5
>     > > > Nov. 2020,
>     > > > wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-v1.1.pdf
>     <http://wakuuenterprises.com/wp-content/uploads/2024/01/mvrxwp-v1.1.pdf>.
>     > > >
>     > > >
>     > > >
>     > > > Best Regards,
>     > > >
>     > > > Wakuu Enterprises, Inc. <http://wakuuenterprises.com/>
>     > > > Newport Beach, CA 92663
>     > > > 949-876-3474
>     > > >
>     > > >
>     > > > On Tue, Jan 23, 2024 at 6:45 PM David Dong via RT <
>     > > > [e-mail]> wrote:
>     > > >
>     > > >> Hi Tony,
>     > > >>
>     > > >> Thanks for filling in the template. Could you fill in "Contact",
>     > > >> "Change
>     > > >> Controller", and "References" fields as well? They were on a second
>     > > >> page.
>     > > >>
>     > > >> We will wait to hear back from the expert whether this would be
>     > > >> eligible
>     > > >> for "permanent" registration. Please see the guidelines in Section 4
>     > > >> for
>     > > >> the distinctions between the two types. A "provisional" registration
>     > > >> can be
>     > > >> made after we hear back from the expert.
>     > > >>
>     > > >> The expert should respond within 2 weeks. For permanent
>     > > >> registrations, if
>     > > >> this is eligible, then there would be an additional three-week
>     > > >> review
>     > > >> period on the uri-review mailing list.
>     > > >>
>     > > >> I will ask the expert to review once we have the completed template.
>     > > >> Thank you.
>     > > >>
>     > > >> Best regards,
>     > > >>
>     > > >> David Dong
>     > > >> IANA Services Sr. Specialist
>     > > >>
>     > > >> On Tue Jan 23 22:54:11 2024, [e-mail] wrote:
>     > > >> > Hi David,
>     > > >> >
>     > > >> > Sure, here is the fulfilled template in Section 7.4 of RFC 7595
>     > > >> > for
>     > > >> > both
>     > > >> > schemes:
>     > > >> >      Scheme name: mvrp
>     > > >> >    Status: Permanent
>     > > >> >    Applications/protocols that use this scheme name:
>     > > >> > Muvor.com, Secure Muvor Protocol, Muvor Virtual Machine, Muvor
>     > > >> > APIs,
>     > > >> > Muvor
>     > > >> > SDK, subsequent derivatives, Muvor Protocol (on-chain) Websites,
>     > > >> > Muvor
>     > > >> > Devices, Muvor OS, Muvor AI, Test Network connections, and more.
>     > > >> >
>     > > >> >
>     > > >> > Scheme name: mvrps
>     > > >> > Status: Permanent
>     > > >> > Applications/protocols that use this scheme name:
>     > > >> >      Muvor.com, Muvor Protocol w/ TLS, Muvor Virtual Machine,
>     > > >> > Muvor
>     > > >> > APIs,
>     > > >> >      Muvor SDK, subsequent derivatives, Muvor Protocol (on-chain)
>     > > >> > Websites,
>     > > >> >      Muvor Devices, Muvor OS, Muvor AI, Main Network connections,
>     > > >> > and more.
>     > > >> >
>     > > >> > How long can I expect this process to take? Both for the
>     > > >> > provisional,
>     > > >> > and permanent?
>     > > >> >
>     > > >> > Thanks again!
>     > > >> >
>     > > >> > Best Regards,
>     > > >> >
>     > > >> > Wakuu Enterprises, Inc. <http://wakuuenterprises.com/>
>     > > >> > Newport Beach, CA 92663
>     > > >> > 949-876-3474
>     > > >> >
>     > > >> >
>     > > >> > On Tue, Jan 23, 2024 at 5:17 PM David Dong via RT <iana-prot-
>     > > >> > [e-mail]>
>     > > >> > wrote:
>     > > >> >
>     > > >> > > Hi Tony,
>     > > >> > >
>     > > >> > > I can send this to the IESG-designated expert to check if this
>     > > >> > > would
>     > > >> > > qualify for a permanent registration.
>     > > >> > >
>     > > >> > > Could you please fill out the template in Section 7.4 of RFC
>     > > >> > > 7595 for
>     > > >> > > your
>     > > >> > > request?
>     > > >> > >
>     > > >> > > Link:
>     > > >> > > https://www.rfc-editor.org/rfc/rfc7595.html#section-7.4
>     > > >> > >
>     > > >> > > Best regards,
>     > > >> > >
>     > > >> > > David Dong
>     > > >> > > IANA Services Sr. Specialist
>     > > >> > >
>     > > >> > > On Tue Jan 23 18:34:24 2024, [e-mail] wrote:
>     > > >> > > > Hi David,
>     > > >> > > >
>     > > >> > > > Thank you for the timely response!
>     > > >> > > >
>     > > >> > > > Is it possible to do both? The provisional now, so that it’s
>     > > >> > > > registered,
>     > > >> > > > while we on the review for the permanent? I believe we should
>     > > >> > > > also
>     > > >> > > > be
>     > > >> > > good
>     > > >> > > > to go in that aspect!
>     > > >> > > >
>     > > >> > > > Thanks again for your help!
>     > > >> > > >
>     > > >> > > > Best Regards,
>     > > >> > > >
>     > > >> > > > Wakuu Enterprises, Inc. <http://wakuuenterprises.com/>
>     > > >> > > > Newport Beach, CA 92663
>     > > >> > > > 949-876-3474
>     > > >> > > >
>     > > >> > > >
>     > > >> > > > On Tue, Jan 23, 2024 at 1:28 PM David Dong via RT <
>     > > >> > > [e-mail]>
>     > > >> > > > wrote:
>     > > >> > > >
>     > > >> > > > > Hi Tony,
>     > > >> > > > >
>     > > >> > > > > Thank you for contacting us.
>     > > >> > > > >
>     > > >> > > > > Could you clarify if you are requesting for a provisional or
>     > > >> > > > > a
>     > > >> > > permanent
>     > > >> > > > > registration? A provisional registration we would be able to
>     > > >> > > > > process
>     > > >> > > now,
>     > > >> > > > > but a permanent registration will require review by the uri-
>     > > >> > > > > review
>     > > >> > > mailing
>     > > >> > > > > list (please see Section 7.2 of RFC 7595 for guidance:
>     > > >> > > > > https://www.rfc-editor.org/rfc/rfc7595.html#section-7.2).
>     > > >> > > > >
>     > > >> > > > > Please let me know how you would like to proceed.
>     > > >> > > > >
>     > > >> > > > > Thank you.
>     > > >> > > > >
>     > > >> > > > > Best regards,
>     > > >> > > > >
>     > > >> > > > > David Dong
>     > > >> > > > > IANA Services Sr. Specialist
>     > > >> > > > >
>     > > >> > > > > On Tue Jan 23 09:47:18 2024, [e-mail] wrote:
>     > > >> > > > > >
>     > > >> > > > > > Contact Name:
>     > > >> > > > > > Tony Walker
>     > > >> > > > > >
>     > > >> > > > > > Contact Email:
>     > > >> > > > > > [e-mail]
>     > > >> > > > > >
>     > > >> > > > > > Type of Assignment:
>     > > >> > > > > > I am requesting a URI Scheme assignment.
>     > > >> > > > > >
>     > > >> > > > > > Registry:
>     > > >> > > > > > Uniform Resource Identifier (URI) Schemes
>     > > >> > > > > >
>     > > >> > > > > > Description:
>     > > >> > > > > > This registration is for a blockchain cloud, and stable-
>     > > >> > > > > > coin,
>     > > >> > > > > > Muvor.
>     > > >> > > > > > It uses custom routing hardware and software in order to
>     > > >> > > > > > securely
>     > > >> > > > > > manage blockchain nodes on the internet. This requires a
>     > > >> > > > > > URI
>     > > >> > > > > > Scheme,
>     > > >> > > > > > so that I can balance and resolve the various internet
>     > > >> > > > > > requests, made
>     > > >> > > > > > by classical computers, to the network nodes, using
>     > > >> > > > > > classical
>     > > >> > > > > > means.
>     > > >> > > > > > This means that even in a post-quantum reality, the main
>     > > >> > > > > > internet
>     > > >> > > will
>     > > >> > > > > > still be at its core. This will also allow the
>     > > >> > > > > > functionality of
>     > > >> > > > > > the
>     > > >> > > > > > some services I have created for this purpose, namely a
>     > > >> > > > > > decentralized
>     > > >> > > > > > cloud.
>     > > >> > > > > >
>     > > >> > > > > > Additional Info:
>     > > >> > > > > > The protocol can be abbreviated mvrp://Wakuu-Enterprises
>     > > >> > > > > > and/or
>     > > >> > > > > > mvrps://Wakuu-Enterprises for Secure Muvor Protocol. It
>     > > >> > > > > > functions
>     > > >> > > with
>     > > >> > > > > > TLS 1.3 and other current security standards, as well as
>     > > >> > > > > > representing
>     > > >> > > > > > the next generation in internet technologies. It uses both
>     > > >> > > > > > TCP
>     > > >> > > > > > and
>     > > >> > > UDP
>     > > >> > > > > > protocols for streaming and routing, respectively, and
>     > > >> > > > > > utilizes
>     > > >> > > > > > the
>     > > >> > > > > > CREB (Create, Read, Emit, Burn) Quantum-Block Method
>     > > >> > > > > > Requests
>     > > >> > > > > > archetype. I suppose this protocol serves as the
>     > > >> > > > > > blockchain
>     > > >> > > > > > alternative to http(s) for reliable streaming
>     > > >> > > > > > transmissions.
>     > > >> > > > > > While
>     > > >> > > on-
>     > > >> > > > > > chain clients create means of resource pooling (games,
>     > > >> > > > > > streams,
>     > > >> > > > > > etc)
>     > > >> > > > > > in order to complete [compute] challenges for its reward
>     > > >> > > > > > (classical
>     > > >> > > > > > proof-of-work). Clients can also create websites, with
>     > > >> > > > > > DNS,
>     > > >> > > > > > create
>     > > >> > > > > > domains, etc, promote market items, affiliate programs,
>     > > >> > > > > > secure
>     > > >> > > pooling
>     > > >> > > > > > databases, decentralized organizations, decentralized
>     > > >> > > > > > users,
>     > > >> > > > > > and a
>     > > >> > > lot
>     > > >> > > > > > more down the road; functioning as a blockchain cloud. For
>     > > >> > > > > > more
>     > > >> > > > > > information, please review the White Paper: WakuuEnt
>     > > >> > > > > > erprises.com/mvrx-whitepaper
>     <http://erprises.com/mvrx-whitepaper>.
>     > > >> > > > >
>     > > >> > > > >
>     > > >> > >
>     > > >> > >
>     > > >>
>     > > >>
>
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review

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