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

so 6. 5. 2023 v 21:37 odesílatel Tim Bray <tbray@textuality.com> napsal:

> I think this provisional registration is a good idea.  One of the central
> premises of Bluesky is that you can migrate your online presence between
> servers without loss of subscriptions or data, and it's hard to see how to
> do this without a URI schema that isn't intrinsically tied to a host, the
> way that "http" URIs are. It remains to be seen if this will actually work,
> but it's a compelling idea.
>

I may be mistaken, but doesnt the did:plc provide migration?

>
> On Sat, May 6, 2023 at 12:28 PM <bnewbold@robocracy.org> wrote:
>
>>
>> [sorry for the dupes folks, trying yet again from personal email after a ]
>> [spam bounce from @blueskyweb.xyz. Have contacted support@ietf.org
>>  ]
>>
>> --------
>>
>> Hi Melvin! Thanks for your comments. Reply in-line below.
>>
>> On Sat, May 6, 2023 at 8:24 AM Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>> > The JSON objects already have 7 different types of identifiers, and
>> > there's more (e.g. CID) and when you replace did:plc it will be at least
>> > 9.  See:
>> >
>>
>> This JSON document is a DID document, in W3C specification. I'm not sure
>> why the number of identifier types is relevant to this URI scheme request.
>>
>> At the level of the at:// URI scheme, we specify that a DID be used, not
>> that did:plc specifically is required. It is true that there are a large
>> number of DID resolution methods, and that from a pragmatic standpoint we
>> strongly recommend only using did:plc and did:web in the AT Protocol
>> ecosystem, but this is not a constraint at the URI scheme level.
>>
>> We will also take this as a reminder to finish formalizing and register
>> the
>> did:plc resolution mechanism with W3C.
>>
>> I think it ought not be an issue to register "at", but I really think you
>> > might be saving yourself some trouble if you hold off for a bit and
>> > complete the protocol.  at:// likely is not needed at all.
>> >
>>
>> Some aspects of the protocol are still under development, but our use of
>> the at:// URI schema is stable. There are third party implementations of
>> the protocol under development, and several independent parties handling
>> real-world data with AT URIs embedded in them. This seems like an
>> appropriate time to provisionally register the URI scheme, and progress to
>> "permanent" registration when the protocol specification matures.
>>
>>
>> > The HTTP identifiers can be done with http:// and the did identifers
>> can
>> > be done with did:, which is part of the design of URIs.  There's not a
>> huge
>> > need to put at:// in front of either, IMHO
>> >
>>
>>   There are several good reasons to have a URI scheme distinct from HTTP
>> in
>> AT Protocol, here are two:
>>
>> Accounts ("repos") in AT Protocol are easy to migrate between service
>> providers. This means that the *location* of the current authoritative
>> host
>> for a repo changes over time. An HTTP URL would indicate one specific
>> location for the repo and would go stale after a migration. As you note
>> above, we *do* use an HTTP URL for the *current* location of the PDS, in
>> the DID document, but this value changes over time, while the AT URIs are
>> intended to be stable.
>>
>> Content in AT Protocol is re-distributable between multiple services and
>> actors, and the mechanism for transportation is flexible. The current
>> protocol uses HTTP and WebSocket, but content can also stored in plan
>> files
>> on disk, etc. There is a need to reference specific records ("resources")
>> regardless of location and transportation mechanism. This is what AT URIs
>> are for.
>>
>> Cheers,
>>
>> --bryan_______________________________________________
>> Uri-review mailing list
>> Uri-review@ietf.org
>> https://www.ietf.org/mailman/listinfo/uri-review
>>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>