Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to call 'URI serialization' #74

Closed
jar398 opened this issue Jul 11, 2023 · 5 comments
Closed

What to call 'URI serialization' #74

jar398 opened this issue Jul 11, 2023 · 5 comments
Labels
duplicate This issue or pull request already exists

Comments

@jar398
Copy link
Contributor

jar398 commented Jul 11, 2023

A comment on #73 (locators spec draft):

I would still prefer that all mentions of 'URI' be removed from the document, even if the syntax of that form satisfies the generic URI syntax. Later, if someone can come up with a good reason for these things being URIs (not just syntactically; and I requested a use case a while ago and no one came forward with one), then there must be some kind of commitment to push an 'ocapn' scheme registration through IETF. And I warn you, that might not be easy - I've been lurking on the uri-review list and submissions routinely get trashed.

We could say 'the string serialization' or 'the ad hoc serialization' or 'the linear serialization' or something like that instead of 'URI serialization'.

A cautionary tale: the LSID spec said that LSIDs were supposed to be URNs, but its URN subscheme (:lsid:) was never even written up, much less registered with IETF. I consider this behavior to be terribly antisocial since it breaks the social contract of the URI and URN specs. Someone coming across an LSID could with reason look up urn: in the URI scheme registry and find the URN spec, then go to the URN subscheme registry (referenced in the URN spec) to find LSID, and they wouldn't find it, endangering their faith in the whole system and reinforcing the idea that it's a free for all (which it is to some extent but only for spec violators).

If :lsid: had been submitted to IETF for review it would have been rejected because there is no way to write a conforming URN registration for it that's consistent with the LSID spec. This is not how things are supposed to work. You might call it 'URIwashing'.

@gibson042
Copy link
Collaborator

I strongly agree with this, and intend to incorporate "URIwashing" into my vocabulary.

@dckc
Copy link
Collaborator

dckc commented Jul 24, 2023

"introduction by serialized reference" is what I suggested in #29

  1. it avoids pre-judging whether these things should be URIs
  2. it gives a use-case: introduction via something like email or the side of a bus or a telephone call:

Then I can call my buddy on the phone and say "I'm 0371 on the agoric board". "What?" "oh-three-seven-one".
-- Feb 16 comment

@dckc
Copy link
Collaborator

dckc commented Jul 24, 2023

You might call it 'URIwashing'.

or "squatting". It's an anti-pattern documented as far back as 2005: UriSpaceSquatting

@jar398
Copy link
Contributor Author

jar398 commented Sep 12, 2023

I see... the document has a section 'URI serialization' which is correctly named... it's in a section called 'Node locator' which includes various serializations. To be compulsively parallel the larger section might be called "Locator serializations". As suggested I'll close this as a dup of #29

@jar398 jar398 added the duplicate This issue or pull request already exists label Sep 12, 2023
@jar398
Copy link
Contributor Author

jar398 commented Sep 12, 2023

Dup of #29

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants