IETF Last Call Review of draft-ietf-cellar-tags-19
review-ietf-cellar-tags-19-artart-lc-turner-2025-10-14-00

Hi! Here's my ARTART review:

NOTE I did not validate the XML examples.

0) s3 (and elsewhere): Often we use example domain names, IP addresses, etc. In
the example presented in s3 (and elsewhere), the I-D uses actual band, person,
and track names. I assume that this is okay and we're not stepping into some
kind of IPR issue with a litigious band member/manager/record company.

1) s3.2.2.1: Why is this not using the time-related ABNF from RFC 3339?

2) s3.2.2.*: I see that RFC 9559 contains text about language codes, but this
I-D does not. Why not?

3) s3: Table 1 and Table 33 of RFC 9559 don’t seem to quite line up. If I
interpret what’s in Table 1 for the lowest level that’s either a dash or
nothing. Table 33 doesn’t seem to allow for those - it allows for “SHOT”.

4) s3: 3rd to last para refers to s24.2 of RFC 9559 for the void string. I
didn’t see it there. Is that the right reference?

5) s4.5: CHOREGRAPHER (also mispelt), COSTUME_DESIGNER, & MIXED_BY
Description’s entries are missing “.” at the end.

6) s4.8: Are multiple values for COMPOSER_NATIONALITY supported for composers
with multiple nationalities?

7) s4.9: s/The number of time the/The number of times the

8) Some thoughts on Security Considerations:

8.1) Some of the tags do allow for “identifying” information to be stored,
e.g., names, email addresses, location, so you probably need to say something
about the privacy implications of including values for these fields.

8.2) COMMENT (s4.9) can be anything so maybe something needs to be said about
not including information in the tag that the person applying the tag wouldn’t
want to share it. E.g., I put “This reminds me of my boss” in COMMENT and then
I stream the track and the track is Johnny Paycheck's “Take this Job and Shove
It” :)

8.3) PURCHASE_INFO (s4.12) is a URL where you can buy somethings so maybe you
need to say something about not blindly following the link to buy something;
i.e., is this a potential phishing vector?

8.4) Since there's no security standardized (as per RFC 9559), might be worth
noting either generally or as it applies to certain tags that you can't rely on
the values present. Like say "LAW_RATING" is set to like "X" and then later
changed to "G" - is that a concern? Or that the PURCHASE_PRICE was $1, but it
gets made $1,000,000.00? Or the date is moved back or up? Or that all of the
legal fields get changed/removed?