[urn] Re: Registration for `c2pa` URN

It's likely more efficient for you to wait until a few other team 
members provide feedback, but feel free to post a revised registration 
request to the list if you'd like. You can keep it at version "1" 
because you would submit "2" only at some point in the indefinite future 
(e.g., with a significantly updated version of the underlying spec).

On 7/30/24 2:37 PM, Leonard Rosenthol wrote:
> Excellent points, Peter – thanks!
> 
> Is it best to just provide just updated sections or would you rather a 
> complete proposal?
> 
> Leonard
> 
> *From: *Peter Saint-Andre <[email protected]>
> *Date: *Tuesday, July 30, 2024 at 4:32 PM
> *To: *Leonard Rosenthol <[email protected]>, [email protected] <[email protected]>
> *Subject: *Re: [urn] Registration for `c2pa` URN
> 
> EXTERNAL: Use caution when clicking on links or opening attachments.
> 
> 
> Hi Leonard, thank you for this registration request. Because it's high
> summer in the northern hemisphere, feedback from other members of the
> expert review team might be delayed. However, in the meantime I have
> provided several small comments inline.
> 
> On 7/30/24 12:36 PM, Leonard Rosenthol wrote:
>> Namespace Identifier:  c2pa
>>
>> Version:  1
>>
>> Date:  2024-07-30
>>
>> Registrant:
>>
>> Leonard Rosenthol, on behalf of C2PA (Coalition for Content Provenance
>> and Authenticity)
>>
>> [email protected] <mailto:[email protected] <mailto:[email protected]>>, 1-215-808-4978
> 
> Typically it's a good idea to include a "role" email address (e.g.,
> [email protected]) instead of a personal one.
> 
>> 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.
>>
>> The `c2pa` URN will consist of a UUID URN (as per RFC 9562) with
>> 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.
>>
>> 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
>>
>> 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.
> 
> You provide information about the Version and Reason string but not
> about the Claim Generator identifier string. For example: are there any
> length restrictions? Can they include code points (characters) only from
> the ASCII range? And so on. It would be good to clarify these matters,
> since comparison is important for your use cases.
> 
> The remainder of the request looks good to me, although you might
> consider pointing to the relevant sections of the c2pa spec regarding
> security issues, since they seem to be covered quite extensively there.
> 
> Peter
> 

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]