Re: [Uri-review] URI Scheme "ves:"

On December 18, 2021 3:53:27 PM EST, Julian Reschke <julian.reschke@gmx.de> wrote:

Am 18.12.2021 um 20:15 schrieb Jim Zubov:

Thanks for the comments -

On 12/18/2021 1:15 PM, Tim Bray wrote:

- Should you also register content-types for these things?

If fact there's already one registered - application/vnd.ves.encrypted

This is not a type VES URI is pointing to, but rather encrypted content
stored by external means, the item encryption key for this content is
identified by a VaultItem VES URI. There are no specific content types
for objects identified by VES URIs, because those are handled by libVES
or an equivalent tool, and are communicated in an e2ee form with the low
level VES REST API as JSON objects.

- Assuming you do, one wonders why you couldn't use regular old https
URLs, if these things are located on a DNS-addressable server.

The API server is DNS addressable, it's api.ves.host, however I see a
few reasons to not use http uri -

- There are forms of VES URI that use an implicit app domain, which
comes from the current context of libVES, or other VES API tool. An http
uri wouldn't have the means to use the current context;

- I purposely specified some permitted violations of URI syntax that VES
URI should tolerate, because it simplifies interactions between the
client software and libVES, without causing any ambiguity;
...

"I purposely specified some permitted violations of URI syntax" -
seriously? That makes it a non-starter for URI registration, IMHO.

Best regards, Julian

I specified the violations, specifically stripped url encoding, that the software SHOULD understand, and libVES is fact DOES understand. The uri parts is still recommended to be properly url encoded to comply with the standards.

Uri-review mailing list
Uri-review@ietf.org
https://www.ietf.org/mailman/listinfo/uri-review

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.