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

[Graham Klyne <[e-mail]>]

Melvin,

In your example, the use of “@“ isn’t a problem.  It’s designated as “reserved” in RFC3986  because it can serve a delimiter role in the authority element of a URI, but it is specifically permitted as a character in a path segment (see ‘pchar’ production in RFC3986).

#g


Sent from my iPhone

> On 19 May 2023, at 12:24, Melvin Carvalho <[e-mail]> wrote:
> 
> 
> 
> 
> 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 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
>>>>> _______________________________________________
>>>>> Uri-review mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/uri-review