[urn] Re: Registration for `c2pa` URN

[Peter Saint-Andre <[e-mail]>]

Well, we did it in Section 2 of RFC 8141 (re-using alphanum, fragment, 
and pchar from RFC 3986), so it's a fine way to do things, but not 
necessary.

On 8/1/24 1:22 PM, Leonard Rosenthol wrote:
> I thought about doing that, but since RFC 9562 didn’t do it – I figured 
> it wasn’t allowed for some reason.
> 
> Leonard
> 
> *From: *Peter Saint-Andre <[e-mail]>
> *Date: *Thursday, August 1, 2024 at 3:19 PM
> *To: *Leonard Rosenthol <[e-mail]>, Dale R. Worley 
> <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *Re: [urn] Re: Registration for `c2pa` URN
> 
> EXTERNAL: Use caution when clicking on links or opening attachments.
> 
> 
> Hi Leonard, thanks for the quick turnaround.
> 
> To simplify the ABNF, you could re-use some of the rules from RFC 3986
> or RFC 5234 rather than (apparently) redefining them here.
> 
> Other than that, it looks good to me.
> 
> Peter
> 
> On 8/1/24 12:58 PM, Leonard Rosenthol wrote:
>> Here is the revised registration proposal.   The links to 2.1 will be
>> live tomorrow (2-Aug-2024).
>>
>> Leonard
>>
>> Namespace Identifier:  c2pa
>>
>> Version:  1
>>
>> Date:  2024-07-30
>>
>> Registrant:
>>
>> Leonard Rosenthol, on behalf of C2PA (Coalition for Content Provenance
>> and Authenticity)
>>
>> [e-mail] <mailto:[e-mail] <mailto:[e-mail]>>, 1-215-808-4978
>>
>> Purpose:
>>
>> Each C2PA Manifest (aka Content Credential) created to incorporate
>> provenance information about a given asset is given a unique identifier
>> which has historically been an incorrectly formatted UUID URN.  This
>> proposal, in conjunction with an updated specification, will define a
>> new `c2pa` URN namespace for this purpose.
>>
>> The `c2pa` URN will consist of a UUID URN (as per RFC 9562), with the
>> namespace changed to 'c2pa' and additional information that is specific
>> to C2PA added.  These URNs are non-resolvable, serving as unique
>> identifiers. In this way, the ability to unambiguously compare them is
>> of significant importance.
>>
>> Syntax:
>>
>> A `c2pa` URN shall consist of two mandatory and two optional components,
>> in the following order, with `:`'s between each section.
>>
>>                  - URN identifier (`urn:c2pa`): REQUIRED
>>
>>                  - UUID v4, in string representation (as per RFC 9562,
>> section 4): REQUIRED
>>
>>                  - Claim Generator identifier string : OPTIONAL
>>
>>                  - Version and Reason string : OPTIONAL
>>
>> When present, the "Claim Generator identifier" string shall consist of
>> no more than 32 characters from the ASCII range (as per RFC 20), but
>> which are not Control Characters (RFC 20, 5.2), Graphic Characters (RFC
>> 20, 5.3), the `:` or the `_`.
>>
>> When present, the "Version and Reason" string shall consist of a `v`
>> followed by a monotonically increasing integer, starting with 1,
>> followed by an underscore (`_`) and then an integer representing the
>> reason for the re-labeling.
>>
>> An ABNF for a `c2pa` URN looks like:
>>
>>                  c2pa_urn = c2pa-namespace UUID [":" claim-generator]
>> [":" version-reason]
>>
>>                  c2pa-namespace = "urn:c2pa:"
>>
>>                  ; this definition is taken from RFC 9562
>>
>>                  UUID     =  4hexOctet "-"
>>
>>
>> 2hexOctet "-"
>>
>>
>> 2hexOctet "-"
>>
>>
>> 2hexOctet "-"
>>
>>                                                                  6hexOctet
>>
>>                  hexOctet = HEXDIG HEXDIG
>>
>>                  DIGIT    = %x30-39
>>
>>                  HEXDIG   = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
>>
>>                  ; ASCII, but not Control Characters, Graphic
>> Characters, `:` or `_`
>>
>>                  visible-char-except-space-colon-underscore = %x21-2B /
>> %x2D-3A / %x3C-7E / %x80-FF
>>
>>                  ; claim-generator-identifier is a string of
>>
>>                  ;               1 to 32
>> visible-char-except-space-colon-underscore
>>
>>                  claim-generator = ":" claim-generator-identifier
>>
>>                  claim-generator-identifier =
>> 1*32visible-char-except-space-colon-underscore
>>
>>                  ; version-reason is a string consisting of a "v"
>> followed by
>>
>>                  ;               a positive integer, an underscore and a
>> second positive integer
>>
>>                  version-reason = ":v" version "_" reason
>>
>>                  version = 1*DIGIT
>>
>>                  reason = 1*DIGIT
>>
>> EXAMPLES:
>>
>>                  - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4`
>>
>>                  - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme`
>>
>>                  - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme:v2_1`
>>
>>                  - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:v2_1`
>>
>> Assignment:
>>
>> URNs conforming to this scheme are self-assigned, based on the creation
>> of the UUID (as per RFC 9562) and the optional inclusion of the Claim
>> Generator identifier string and Version and Reason. This process is
>> described at
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_unique_identifiers&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569277617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=9rBAhiGg3vy2st66CDmMH0I%2BjICe7%2BhoXjUi6JGr2e4%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_unique_identifiers> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_unique_identifiers&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569291331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QS4o5GL%2F8CmgEyyO64JNB4JM7smDzea2H0hlGNyEVWw%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_unique_identifiers>>
>>
>> Security and Privacy:
>>
>> No known security or privacy issues exist for this specific URN,
>> however, the C2PA specification maintains a "Information Security"
>> section
>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_information_security&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569299706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=75jPvqVwa9EPv%2Bg9kYY9ih7B0IG24C8v9ch2ZL6RcCI%3D&reserved=0 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html%23_information_security&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569305741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OpLLVhlHfvfX6XTXIi5cMHMrUgtVEIf536P8blcSw7g%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_information_security>>) which documents any known threats and harms related to the core C2PA specification.
>>
>> Interoperability:
>>
>> A standard UUID URN can be "losslessly upgraded" to a `c2pa` UUID, if
>> there were to exist a workflow that required doing so.  Beyond that, no
>> known concerns or requirements around interoperability exist.
>>
>> Resolution:
>>
>> As mentioned earlier in this document, these URNs are non-resolvable,
>> serving as unique identifiers. In this way, the ability to unambiguously
>> compare them is of significant importance.
>>
>> Documentation:
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569310893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Ble45Amx7pJw1NGQw7VcbTx6Fnb7IdoDXnli%2FpeWUE4%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569315849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=13IoUimLrQzpq7x9btLew5h26%2F%2F5RskucC85V5CH%2BpM%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html>>
>>
>> Additional Information:  NONE
>>
>> Revision Information:  N/A
>>
>> *From: *Dale R. Worley <[e-mail]>
>> *Date: *Thursday, August 1, 2024 at 2:23 PM
>> *To: *Leonard Rosenthol <[e-mail]>
>> *Cc: *[e-mail] <[e-mail]>
>> *Subject: *Re: [urn] Registration for `c2pa` URN
>>
>> EXTERNAL: Use caution when clicking on links or opening attachments.
>>
>>
>> The overall concept looks fine.  I have the following comments.
>>
>>> Namespace Identifier:  c2pa
>>>
>>> Version:  1
>>>
>>> Date:  2024-07-30
>>>
>>> Registrant:
>>> Leonard Rosenthol, on behalf of C2PA (Coalition for Content Provenance
>>> and Authenticity)
>>> [e-mail]<mailto:[e-mail] <mailto:[e-mail] <mailto:[e-mail]>>>, 1-215-808-4978
>>
>> As Peter says, the contact identification should be chosen to be stable
>> as long as possible.
>>
>>> Purpose:
>>>
>>> Each C2PA Manifest (aka Content Credential) created to incorporate
>>> provenance information about a given asset is given a unique
>>> identifier which has historically been an incorrectly formatted UUID
>>> URN.  This proposal, in conjunction with an updated specification,
>>> will define a new `c2pa` URN syntax for this purpose.
>>
>> Change "URN syntax" to "URN namespace".
>>
>>> The `c2pa` URN will consist of a UUID URN (as per RFC 9562) with
>>
>> You probably want to add "the namespace changed to 'c2pa', with" here.
>>
>>> additional information, specific to C2PA added.  These URNs are
>>> non-resolvable, simply serving as unique identifiers. In this way, the
>>> ability to unambiguously compare them is of significant importance.
>>
>> Though it seems from the 3rd and 4th fields, the URNs aren't *just*
>> unique identifiers, the identifier is tagged with some semantic
>> information.  So you might want to expand on that here.
>>
>>> Syntax:
>>>
>>> A `c2pa` URN shall consist of two mandatory and two optional
>>> components, in the following order, with `:`'s between each section.
>>>
>>>                 - URN identifier (`urn:c2pa`): REQUIRED
>>>                 - UUID v4, in string representation (as per RFC 9562, section 4): REQUIRED
>>>                 - Claim Generator identifier string : OPTIONAL
>>>                 - Version and Reason string (as described below) : OPTIONAL
>>
>> You really ought to provide ABNF here.  E.g., this text says that the
>> 3rd and 4th parts are both optional, but it's not clear, if only one of
>> them is present in a URN, which one is present.  It appears from the
>> examples that if the 4th part is present, then the 3rd (or at least the
>> colon that starts it) must be.  What you're looking for is something
>> like:
>>
>> c2pa_urn = "urn:c2pa:"
>>             UUID         ; from RFC 4122
>>             [ ":" [ claim_generator ]
>>               [ ":" version_reason ] ]
>>
>> Of course, we need some idea what the syntax of "claim_generator" is.
>> At least it must not contain a colon!
>>
>>> When present, the "Version and Reason" string shall consist of a `v`
>>> followed by a monotonically increasing integer, starting with 1,
>>> followed by an underscore (`_`) and then an integer representing the
>>> reason for the re-labeling.
>>
>> version_reason = version "_" reason
>> version        = "v" %31-39 *%30-39    ; "v" and a positive decimal
>> integer (see RFC 2234)
>>
>> But it's not clear what the syntax or semantics of "reason" is.
>>
>>> EXAMPLES:
>>>
>>>                 - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4`
>>>                 - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme`
>>>                 - `urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4:acme:v2_1`
>>
>> It's always good to have examples!
>>
>>> Assignment:
>>>
>>> URNs conforming to this scheme are self-assigned, based on the
>>> creation of the UUID (as per RFC 9562) and the optional inclusion of
>>> the Claim Generator identifier string and Version and Reason.
>>
>> It would be helpful to have some description of the syntax and semantics
>> of the claim_generator and reason fields.  If the C2PA web specification
>> has a concise description, a link to that would be sufficient.
>>
>>> Security and Privacy:
>>>
>>> No known security or privacy issues exist.
>>
>> As Peter says, not only does
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.0%2Fspecs%2FC2PA_Specification.html%23_information_security&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569322489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EC4nf%2FKJlFd%2FObrLd2YxdMNmlpzV7%2BpMcj2X0IPCwlg%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_information_security> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.0%2Fspecs%2FC2PA_Specification.html%23_information_security&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569327932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vbRrtLI8NAkg3q%2FwT2Z50ikfsq9Yt52H8HWXC1gBIco%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_information_security>>
>> give extensive security discussion (which might just be pointed to here)
>> but its existence shows that there *are* known security issues,
>> contradicting this text.
>>
>>> Interoperability:
>>>
>>> A standard UUID URN can be "losslessly upgraded" to a `c2pa` UUID, if
>>> there were to exist a workflow that required doing so.  Beyond that,
>>> no known concerns or requirements around interoperability exist.
>>>
>>> Resolution:  N/A
>>
>> You might want to move the sentences "These URNs are non-resolvable ..."
>> to this section.
>>
>>> Documentation:  https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569334597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B5xspyCmELLrJsmwbV2hJQmoCC6B5lO94P948hqvcF8%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fc2pa.org%2Fspecifications%2Fspecifications%2F2.1%2Fspecs%2FC2PA_Specification.html&data=05%7C02%7Clrosenth%40adobe.com%7C4a00b8a175fa452bde2408dcb25ed445%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638581367569340845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JLize5PZoIg4o%2Fjme4XEReUyHWLDV%2BpbutHhl3LCc4w%3D&reserved=0 <https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html>>
>>>
>>> NOTE: Version 2.1 is not yet published but will contain this documentation when published
>>
>> How shall we handle this?  It's not proper to register a URN namespace
>> if its references do not exist.  Is there an earlier version of the
>> specification which is "good enough" to link to as documentation?
>>
>> Of course, when new version(s) of the C2PA spec are published, it's easy
>> enough to register a new version of the URN to update the documentation
>> pointer.
>>
>>> Additional Information:  NONE
>>>
>>> Revision Information:  N/A
>>
>> Dale
>>
>>
>> _______________________________________________
>> urn mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>