[Cellar] Re: draft-ietf-cellar-tags-19 ietf last call Artart review

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Sean,

I have a couple of things that occurred to me on your as always excellent
review. Please see below.

Hi, Steve,

I've approved all the PRs for the tags specification. I made a couple of
suggestions, but I trust the authors to Do The Right Thing with them.

If we hear back from Sean about my thoughts before November 1, we'll Do The
Right Thing. If not, Sean and Robert are both registered for IETF 124 as
onsite attendees, and they know each other by sight. 😁

On Sun, Oct 19, 2025 at 8:45 AM Steve Lhomme <[e-mail]> wrote:

> Hi,
>
> On 14 Oct 2025, at 22:48, Sean Turner via Datatracker <[e-mail]>
> wrote:
>
> Document: draft-ietf-cellar-tags
> Title: Matroska Media Container Tag Specifications
> Reviewer: Sean Turner
> Review result: Ready with Issues
>
> 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.
>
>
> There is an example from Daft Punk and one from The Orb. The links
> provided to illustrate the examples and give a usable reference are on
> discogs.com which is like a Wikipedia for recorded music (with a way to
> buy the things as well). All data are entered by users. I don’t think there
> was any problem about using a track listing with durations anywhere. We’re
> using “metadata” about the content which I don’t think are copyrighted,
> unlike the music or cover art that comes with it.
>

Sean, is it accurate (in your opinion) to say that the purpose of
http://rfc-editor.org/rfc/rfc6761 Section 6.5 (if that's the right
reference) is to prevent implementers from clobbering domain names that
someone else controls by simply reusing names from an RFC?

ISTM that in this case, we are actively encouraging implementers to go look
at the domain names we don't control, because we like the resource stored
there.

That might qualify as an example, but it's not a
http://rfc-editor.org/rfc/rfc6761 Section 6.5 *.example.*" example.

Does that make sense?


> 1) s3.2.2.1: Why is this not using the time-related ABNF from RFC 3339?
>
>
> It says why in the text. It’s not the same date format, in particular it
> adds milliseconds.
>
> 2) s3.2.2.*: I see that RFC 9559 contains text about language codes, but
> this
> I-D does not. Why not?
>
>
> The TagString element is defined in RFC 9559 as UTF-8. The language to use
> to classify each string is defined by the TagLanguage and TagLanguageBCP47
> elements that can be found in the parent SimpleTag element.
>
> This new document doesn’t mention them because there is probably nothing
> more to add than already found in RFC 9559.
>
> 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”.
>
>
> Table 1 of the new document and Table 33 of RFC 9559 are basically the
> same table split in two to distinguish the values for audio and video. For
> Audio I couldn’t think of an equivalent for a SHOT. Maybe the dash line
> should be removed to avoid any confusion.
>
> Note these strings are just informational, so whatever string you put in
> the TargetType doesn’t really matter (even if it’s a dash).
>
> 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?
>
>
> This is referring to this part of the section:
>
> If an upper value doesn't apply to a level but the actual value to use is
> not known, an empty TagString (Section 5.1.8.1.2.5
> <https://www.rfc-editor.org/rfc/rfc9559#tagstring-element>) or an empty
> TagBinary (Section 5.1.8.1.2.6
> <https://www.rfc-editor.org/rfc/rfc9559#tagbinary-element>) MUST be used
> as the tag value for this level.
>
> I changed the text to use the same wording in
> https://github.com/ietf-wg-cellar/matroska-specification/pull/1036
>
> “the value MUST be set to an empty string "" as detailed in Section 24.2
> <https://rfc-editor.org/rfc/rfc9559#section-24.2> of [RFC9559],"
>
> 5) s4.5: CHOREGRAPHER (also mispelt), COSTUME_DESIGNER, & MIXED_BY
> Description’s entries are missing “.” at the end.
>
>
> I added the fix with typo fix in
> https://github.com/ietf-wg-cellar/matroska-specification/pull/1034
>
> 6) s4.8: Are multiple values for COMPOSER_NATIONALITY supported for
> composers
> with multiple nationalities?
>
>
> Yes, you can use multiple times the same tag name at any level to “add”
> values. It’s better than putting all the values in a single element. See
> section 3.2.2.
>
> 7) s4.9: s/The number of time the/The number of times the
>
>
> Also added to
> https://github.com/ietf-wg-cellar/matroska-specification/pull/1034
>
> 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.
>
>
> Indeed!
> I proposed a new section here
> https://github.com/ietf-wg-cellar/matroska-specification/pull/1037
>
> 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” :)
>
>
> I added both “nested information” and “user information” in the tag values
> that may need restricted access for things that should not go public, (or
> in the wrong circles).
>
> 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?
>
>
> Indeed. We used to have other URLs in the format but we removed them. So
> tags are the only place where there is one.
> I proposed a new section here
> https://github.com/ietf-wg-cellar/matroska-specification/pull/1038
>
> 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?
>
>
> This is a valid concern. However I’m not sure how we would say anything
> about that. These values are informational. They are definitely not legally
> binding when you use the file. Anything using these values as tamper-proof
> would be broken.
>

Sean/Steve, is the point here that it's not possible to detect when a tag
has been modified, either innocently or maliciously?

If https://www.rfc-editor.org/rfc/rfc9559#name-security-considerations
handles this, it seems to be in this text:

*Matroska Reader implementations need to be robust against malicious
payloads. Those related to denial of service are outlined in Section 2.1 of
[RFC4732].*


and https://www.rfc-editor.org/rfc/rfc4732.html is, of course, focused on
malicious DoS attacks - "denying a user of the service of their money"
doesn't seem quite the same as what RFC 4732 is talking about.

If we need to say something about unprotected tags, I would think that
needs to happen in the base Matroska specification (RFC 9559), rather than
being handled in -tags.

Does that make sense?

Best,

Spencer


> Thanks again,
> Steve
> _______________________________________________
> Cellar mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>