Comments on the draft of May 21 for ICRC-76
@skilesare, thanks a lot for the write up, this is already very nice! With the changes from the recent meeting it has really become very powerful, yet simple.
Some comments that we may want to discuss towards finalizing it follow below. We may want to cover some of those in the meeting this afternoon.
-
Editorial: “Metadata is hosted externally”. 2. This is not true for data URIs, we need to rephrase this. E.g., “Metadata is accessible via a specified URI, which can either be a pointer to a JSON file hosted externally or a data URI as specified in RFC 2397.”, or similar.
-
We should make explicit how a URI for URI-based metadata is expressed through a
Value. -
Maybe we should make explicit that any valid URI can be used and that the presented examples are the major prominent examples of schemes, but not exhaustive.
-
ic-uri seems to be a concept that is valuable also outside of this domain. The question is whether a generic standard would require further refinement. If so, we may want to refrain from making it separate now in order to not try to boil the ocean, but include it here and maybe factor a generalized variant out in the future as a separate ICRC.
-
Is the IC-URI only intended to address resources exposed through the http_request method of canisters? If so, would a URI scheme that addresses the native canister interface also be useful?
-
Mixing the approaches of representing metadata should be allowed, e.g., to have small metadata items directly expressed, but large ones like images linked via URL. This may be a prominent use case for practical scenarios. Making explicit that this is possible would be geat (if we agree that it is). We should present the structure how this would look like. Also, allowing for multiple metadata references may make sense, e.g., to combine metadata from different external locations. This is currently implicit (or even unsupported), but something that we may want to have.
-
Overall, we may want to make the difference between URI and URL more explicit. URIs are not followed, they are merely an “Identifier” (the “I” in “URI”). URLs are followed, the “L” stands for “Locator” in “URL”.
-
URI-based metadata can again point to further metadata items, like images in a remote JSON file. This makes following recursive. We should make this explicit, otherwise it seems that there is only one level of following indirection.
-
Some outstanding questions on what to do about data in metadata that is Text, a URI, but NOT supposed to be traversed and included in the metadata. (Choice one is to have a specific tag in a map for this type of data ie icrc76:no_follow or two to have a tag for followable links ie icrc76:metadata:follow).
→ URIs are often used as identifiers that are not followed because URIs are essentially the only reasonable global namespacing system, so not following may be the default case without a tag, while following having a tag “icrc76:metadata:follow” might make most sense. -
We may want to reserve already an ICRC number for the OpenSea-specific standard and maybe others as well.