[Rats] Re: UCCS and EAT media types (was: Re: Re: AD follow-up review of draft-ietf-rats-uccs-09)

[Henk Birkholz <[e-mail]>]

Hi Carsten & Thomas,

it is perfectly fine to define useful informative CDDL definitions in an 
Appendix (that we have to mark as informative) and then let other 
specification use that definition in an informative or normative manner.

It is also very useful :-) I do not think that removing the UJCS 
reference from draft-ietf-rats-eat-media-type is useful or necessary, 
though. I am slightly leaning towards the UCCS spec handling its 
media-type definition, but (!) we could also up-level to 
rats-media-types, yes?


Viele Grüße,

Henk

On 03.06.24 17:09, Carsten Bormann wrote:
> 
> 
>> On 2024-06-03, at 09:46, Thomas Fossati <[e-mail]> wrote:
>>
>> Hi Carsten,
>>
>> On Fri, 31 May 2024 at 22:45, Carsten Bormann <[e-mail]> wrote:
>>>> I don’t understand.  This CDDL in Appendix A is normative, and so is the flexibility in its design to support JSON.  Otherwise, it would be “C< ...>” and not “JC<...>”.  I don’t take exception with providing a JSON binding but please explain this in the prose and in the introduction..
>>>
>>> We now made it explicit that this is there as “CDDL you can use” — a normative intent when actually using this is desirable but the CDDL itself is not changing the specifications in any way, hence it is an informative appendix.  Line 462..465.
>>
>> Hence, UJCS is *not* defined by draft-ietf-rats-uccs.  Correct?
> 
> Well, it is *defined*.
> It is another name for the JWT claims set as defined in RFC 7519.
> The UCCS document simply supplies CDDL that can be used for this.
> The UCCS document also describes the role an unprotected claims set can have in the RATS context, specifically for UCCS.
> There is no normative intent with this definition beyond that, but the description of the role of UCCS can be analogously applied to UJCS.
> The normative intent of referencing UJCS would be in the document that uses this CDDL definition normatively.
> Interestingly, Section 4.2.18 already reads exactly like this, without using the term UJCS (it only gives UCCS as an example).
> 
>> If so, we need to remove it from draft-ietf-rats-eat-media-type.
> 
> I don’t think that this is necessarily following.
> 
>> As an aside, I am starting to wonder whether it'd be better for
>> draft-ietf-rats-eat-media-type to just drop the registrations for UCCS
>> and let draft-ietf-rats-uccs handle it.
> 
> I think this could also very well be done (media type and content format, that is).
> Is there a need to have “eat” in the name?
> (I would probably also let the names reveal that UJCS and UCCS are not exactly the same data structures, so this would be application/uccs+cbor and application/ujcs+json.)
> 
>> Transplanting Section 6.7 [1] and moving the "ucs" line from Table 2
>> [2] should do the trick, and disentangle the fate of the two
>> documents.
>>
>> cheers, t
>>
>> [1] https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-07.html#section-6.7
>> [2] https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-07.html#table-2
> 
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]