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

[Melvin Carvalho <[e-mail]>]

po 8. 5. 2023 v 18:40 odesílatel Tim Bray <[e-mail]> napsal:

> What Ted said.  I'd go all the way to "atproto" because
> https://en.wikipedia.org/wiki/ATP
>
> The one really good argument I can see for sticking with "at" would be:
> Are users of systems based on ATProto going to be seeing, thinking about,
> and copy/pasting lots of these URIs? If so, there’s a case for brevity and
> wit.
>

There is a viewpoint suggesting that using "atproto://" could be more
beneficial for users when it comes to interacting with and remembering URIs.

For example,

http://mybank.example : would naturally lead users to their bank, while
at://mybank.example : may cause confusion or accidental deferencing. In
contrast,
atproto://mybank.example : offers a visual indication that it might not
rely on the conventional domain name system.

Adopting this approach could enhance security and minimize the risk of
phishing attacks.


>
> On Mon, May 8, 2023 at 2:54 AM Ted Hardie <[e-mail]> wrote:
>
>> I agree with Eliot here.  The registry is first-come-first-served because
>> we want to avoid collisions; having a single namespace for this is pretty
>> much a requirement for the overall system to function properly.   But,
>> as you can tell, there is a period after a string is minted internally and
>> starts turning up in code before it shows up at the registry (or even on
>> this list).  Very short strings and strings with mnemonic significance
>> (like the wordplay that led you to "at") are at increased risk for
>> collision.
>>
>> Your repo refers to this consistently as atproto, and atproto or even atp
>> is less like likely to create a later collision; my advice (and it is just
>> advice) is to consider using one of those.
>>
>> regards,
>>
>> Ted Hardie
>>
>>
>> On Mon, May 8, 2023 at 9:18 AM Eliot Lear <[e-mail]> 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
>>>
>> _______________________________________________
>> Uri-review mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uri-review
>>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>