Re: [Uri-review] Registration request for "at" URI scheme

[Melvin Carvalho <[e-mail]>]

ne 14. 5. 2023 v 9:33 odesílatel Melvin Carvalho <[e-mail]>
napsal:

>
>
> st 10. 5. 2023 v 21:16 odesílatel Paul Frazee <[e-mail]> napsal:
>
>> Why don't I get a writeup done to clear up questions (I apologize for not
>> leading with one). I'll address what you're suggesting/asking about,
>> Melvin, and some of the other questions. While I'm working on that, feel
>> free to drop in more questions and I'll include them in the writeup.
>>
>
> Looking forward to that.
>
> I do feel that the short nature of "at://" could lead to confusion with
> other URI schemes. Recently it was remarked "dhttp" could be easily
> mistaken for "http", with a typing error (leaving out a preceding space). I
> can't help but observe, the previously registered provisional "dat:" scheme
> [1] (coincidentally registered by a P. Frazee), is also quite compact, and
> has a similar collision possibility.
>
> The "at://" scheme had a different name ("adx") less than 9 months ago
> [2], before rebranding, which may indicate potential instability.  See
> quote: "uris should be of the form adx://did/namespace/dataset/tid" [3]
>
> Might I suggest considering "atproto://" or "atp://" as more future
> proofed? They maintain the core concept but could help to avoid future
> conflicts.
>
> [1] https://www.iana.org/assignments/uri-schemes/prov/dat
>
> [2]
> https://github.com/bluesky-social/atproto/tree/c23df960a9bd353bf167e555d1a37c5ad7c14661
>
> [3] https://github.com/bluesky-social/atproto/pull/162
>

Another issue with overloading the use of @.  Consider the following URI,
currently in use by bluesky

https://cdn.bsky.social/imgproxy/DcMz_zK0MX3kbzgp9DPoUgMOzpnpAG_m5ByJuCeV8tQ/rs:fit:1000:1000:1:0/plain/bafkreihbye24in36i6svkn7k5owztzvon7frbcze3lyklmxsogak2m2z6e@jpeg

Regarding the use of "@jpeg" at the end, if I am not mistaken, @ is a
"reserved character" in RFC 3986


>
>
>>
>> Paul
>>
>> On Wed, May 10, 2023 at 1:29 PM Melvin Carvalho <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> st 10. 5. 2023 v 19:29 odesílatel Paul Frazee <[e-mail]>
>>> napsal:
>>>
>>>> The idea is indeed that at:// could user-facing in the same way http://
>>>> is. The intent is to express a social address so that I could be at://
>>>> pfrazee.com to provide a social identity and http://pfrazee.com to
>>>> provide a website. We're hoping to make the scheme intuitive to people, as
>>>> it has a clear connection to the "@pfrazee.com" convention.
>>>>
>>>> I can understand the hesitance around what we're proposing. It's a
>>>> common word and assigning it to an early project is a big ask. I'd like to
>>>> keep the scheme because I believe it's user-friendly, but I also don't want
>>>> to push something that people aren't comfortable with.
>>>>
>>>> My question from here is, is there a way forward to address the
>>>> concerns around this proposal, or do folks feel like this proposal is a
>>>> non-starter? If there is a path forward, how can we help get there?
>>>>
>>>
>>> Potential Approach
>>>
>>> I've noticed similarities between Webfinger, which aimed to return JSON
>>> from a DNS-like identifier with an "@" symbol, and your current situation.
>>> Webfinger eventually established the acct: URI scheme. However, in 2012,
>>> Mark Nottingham suggested an alternative lookup method, such as
>>> ".well-known/webfinger?user=bob@host".
>>>
>>> You might consider registering an "atprotocol" under .well-known and use
>>> the following format: ".well-known/atprotocol?user=<atproto_identifier>".
>>> If the dereferencing is handled by the BGS rather than individual hosts,
>>> perhaps a simple lookup would suffice, eliminating the need for a new URI
>>> scheme.
>>>
>>>
>>>>
>>>> Paul
>>>>
>>>> On Wed, May 10, 2023 at 10:54 AM Graham Klyne <[e-mail]>
>>>> wrote:
>>>>
>>>>> A small clarification to Eliot's comment: the *provisional* registry
>>>>> is FCFS, but there is still a possibility for a hold-up come the time this
>>>>> is advanced to a permanent registration.  The good news is that by raising
>>>>> this here and now (rather than waiting for a permanent registration
>>>>> review), there's a better chance that a consensus on this issue can emerge
>>>>> before the protocol is very widely deployed.  So, thank you for doing that!
>>>>>
>>>>> #g
>>>>>
>>>>>
>>>>> On 08/05/2023 09:18, Eliot Lear wrote:
>>>>>
>>>>> Hi Bryan,
>>>>>
>>>>> As Alex mentioned, I wasn't referring to URI schemes, but rather that
>>>>> the word "at" is not descript, reused in many different contexts, from
>>>>> Austria to a preposition, to a scheduling command in UNIX to various other
>>>>> acronym expansions.  My understanding is that the registry is FCFS, and so
>>>>> this is *advice*.  Whatever you choose you'll be stuck with.  If you
>>>>> even added an extra character or two that could make more clear what this
>>>>> is, you may find it helpful later on.
>>>>>
>>>>> Eliot
>>>>> On 08.05.23 00:14, [e-mail] wrote:
>>>>>
>>>>>
>>>>> Hi Eliot,
>>>>>
>>>>> We did do both some general search, and checked against the URI schema
>>>>> registry when starting work on the protocol, and are not aware of any
>>>>> problematic existing use or conflicts the the use of the URI scheme name.
>>>>>
>>>>> The closest confusion we are aware of with 'at' is the Hayes AT
>>>>> command originally used with modems. We are unaware of any URI scheme
>>>>> specifically for the Hayes AT command set, and while that command set is
>>>>> still in broad use, it does not seem likely to start using one now.
>>>>>
>>>>> "at" matches our protocol name ("AT" stands for "Authenticated
>>>>> Transfer"). There is a bit of wordplay going on with "@" (the "at symbol"),
>>>>> which is used as a prefix convention in social media to indicate a user
>>>>> handle. AT Protocol is primarily used for social media applications (at
>>>>> least, that is the focus at present).
>>>>>
>>>>> As precedent, there are several other two-character URI schemes in the
>>>>> current registry.
>>>>>
>>>>> URIs starting with "at://" are already being used by several
>>>>> implementations of the AT Protocol. At this point it seems like a change
>>>>> would only add to confusion.
>>>>>
>>>>> --bryan
>>>>>
>>>>> On Sun, 7 May 2023, Eliot Lear wrote:
>>>>>
>>>>> As another casual observer, can I suggest that you use a slightly more
>>>>> descriptive scheme name?  "at" is heavily overloaded, and a name that
>>>>> provides at least a guess what this is will serve the user better.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Uri-review mailing [e-mail]://www.ietf.org/mailman/listinfo/uri-review
>>>>>
>>>>> --
>>>>> Graham Klynemailto:[e-mail] <[e-mail]>http://www.ninebynine.org
>>>>> Mastodon: @[e-mail]
>>>>> GitHub/Skype: @gklyne
>>>>>
>>>>> _______________________________________________
>>>> Uri-review mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/uri-review
>>>>
>>>