[media-types] Re: WG Last Call: draft-ietf-mediaman-6838bi s-06

Hello everybody,

This continues my review comments of yesterday. BTW, I also support 
Alexey's recent comments; I think it's very important that the 
registration process works well for the designated experts, because 
there are many registrations (almost daily, as all the subscribers to 
this list know well). If the other designated reviewers haven't yet 
reviewed this spec, then I think it would be good to invite them 
directly to do so.

Sorry, ran out of time today. Will continue tomorrow.


2.4 Parameters: A syntax for parameters (not just parameter names), i.e. 
including parameter values, separator(s?) between parameter names and 
values, and separators between parameters (and between the media type 
and the parameters is completely missing.

Saying "Note that a protocol can impose further restrictions on 
parameter value syntax..." is not enough (especially because it said 
"There is no defined syntax for parameter values" just a bit earlier). 
At least be straightforward and say that the syntax of parameters is not 
defined in this specification, but in specifications that use media 
types. Ideally, we would lift out these definitions from MIME (RFC 
2045,...) and HTTP into the specification at hand, because the 
differences between these two specs should be minimal, ideally zero. 
This would also be helpful for any future users of this spec.

2.7 Security: "(or are required be taken by applications)" ->
"(or are required *to* be taken by applications)"


Terminology streamlining: Section 3 (taken from RFC 9694) uses 
"top-level (media) type" for the part to the left of the slash. The rest 
of the current draft mostly uses "type" (with "subtype" for the part to 
the right of the slash). The term "media type" is used for the 
combination of type/subtype. The term "content type" also turns up once 
in Section 2.4 (and once in the references). When I worked on RFC 9694, 
I found the use of "type" for the part to the left of the slash not 
precise enough. I would strongly advise that this document similarly 
tighten up terminology, makes sure that the whole document uses uniform 
terminology, and add a paragraph in the intro explaining the choices.

I didn't review section 3, because I'm not good at reviewing text that I 
have read (or written) before.


4.1.1: The intro paragraph should mention "community formats". For 
example, replace "The standards tree is intended for those media types 
that require a substantive review and approval process in a recognized 
standards-related organization." with "The standards tree is intended 
for those media types that require a substantive review and approval 
process, and are (or are expected to be) widely implemented." or 
something similar.

4.1.1.1: Having some short introductory text directly in a section, and 
then several subsections, is a sign of good document orientation. Having 
a lot of introductory text and then only a single smaller subsection is 
bad style. Please split 4.1.1 into at least two (1. standards orgs incl. 
IETF, 2. community formats) or three (IESG/standards orgs/community 
formats) subsections after some intro text. Having three parts will help 
disentangle the IESG case from the standards orgs case.

4.1.5. Additional Registration Trees
"New top-level registration trees may be created by IETF Standards 
Action.": Please remove the word "top-level" here. Despite the word 
"tree", which suggests a multi-level hierachy, media type registration 
trees have only a single level, and so "top-level" here is confusing. 
It's also confusing because of the heavy use of "top-level" in section.

The only marked tree that is in wide use is vnd., and standards 
organizations now have access to the standards tree (which wasn't the 
case originally, see 
https://datatracker.ietf.org/doc/html/rfc2048#section-2.1.1). In 
addition, we have "community formats", which cover an additional range 
of possibilities. Therefore, I think it would be appropriate to reduce 
section 4.1.5 to something like
"New registration trees may be created by IETF Standards Action. No such 
new registrations are currently envisioned."
We can go through an exercise similar to the one for RFC 9694 if ever a 
need for a new tree should show up.


4.2 Structured Syntax Suffixes
"using use a "+suffix" convention." -> "use a "+suffix" convention.

"For example, in the "application/foo+bar" media type "application" is 
the top-level type, "foo" is the subtype name, and "+bar" is the 
structured syntax suffix.": Why is it "subtype name" while only 
"top-level type" and "structure syntax suffix"? I Suggest to streamline 
"subtype name" to "subtype" only.

"SHOULD be semantically aligned": This paragraph uses the term "subtype 
(name)" for "application/foo", where otherwise, it's used for "foo" or 
in this case "foo+baz"/"foo+bar". Please clean up terminology here. 
Probably using something more evocative than "foo" would help here.

Regards,   Martin.



On 2025-10-15 20:15, Martin J. Dürst wrote:
> Hello Harald, others,
> 
> I have read draft-ietf-mediaman-6838bis-06, and oppose publication in
> its current form, for the reasons below.
> 
> I have found a few things that I think should be fixed before sending 
> this for IETF-wide last call.
> 
> - Grammar difference between title and abstract:
>    the title has "Media Type Specifications and Registration Procedures",
>    the abstract has "procedures for the specification and registration
>    of media types". Are specifications separate from procedures (title),
>    or do we give specifications for procedures (abstract)? We should
>    be consistent here.
> 
> - Intro: "are capable of carrying arbitrary labeled content":
>    It's easy to misread this as "arbitrarily labeled content".
>    Maybe better "arbitrary content, if properly labeled".
> 
> - "or even certification that the specification is adequate":
>    "certification" is a very high bar. I think something like
>    "or any kind of assertion that the specification is adequate"
>    would be more appropriate.
> 
> - "All registered media types MUST employ a single,
>    canonical data format": This can easily be read to say that e.g.
>    only Canonical XML, Canonical CBOR, Canonical JSON, and so on
>    are allowed. That's clearly not what we want to say.
>    Maybe the intent is to disallow something like xml-or-json
>    (if the first character is '<', it's XML, if the first character
>     is '{', it's JSON), but I don't think disallowing this should
>    be necessary: As long as the idea sounds silly, nobody should
>    be interested in a registration anyway. Later, if somebody can show
>    a good use case, there's no need to oppose registration.
> 
> - 2.3: Naming: I'd expect the document to say somewhere that
>    (top-level) type and subtype are separated by a slash. But the word
>    'slash' doesn't appear in the document at all. There's also
>    no grammar rule for a full media type.
> 
> I'm sorry I didn't get any further than section 2.3, but I'll continue 
> my review tomorrow.
> 
> Regards,   Martin.
> 
> 
> On 2025-10-02 21:13, Harald Alvestrand wrote:
>> This message initiates a Working Group Last Call on draft-ietf- 
>> mediaman-6838bis-06.
>>
>> The Last Call lasts for 2 weeks, and ends on October 16, 2025, at 
>> 23:59 GMT.
>>
>> To respond to the Last Call, respond on the mailing list with one of 
>> three forms:
>>
>> - I have read draft-ietf-mediaman-6838bis-06, and think that it can be 
>> sent to the IESG for approval with no changes.
>>
>> - I have read draft-ietf-mediaman-6838bis-06, and think that it can be 
>> sent to the IESG for approval with the following issues fixed: 
>> (reference to github issues)
>>
>> - I have read draft-ietf-mediaman-6838bis-06, and oppose publication 
>> in its current form, for the reasons given in (reference to github 
>> issues, or inline reasons)
>>
>> There are a number of issues open on the draft, resulting from 
>> preliminary reviews, but the chairs judge these to be relatively minor 
>> - they need to be resolved one way or the other before we send the 
>> draft to the IESG, but the chairs think that how we resolve these will 
>> not affect whether or not the WG has consensus to ask for publication; 
>> people who disagree with this should use form 3 above.
>>
>> If the result of the WG Last Call is conclusive, we may be able to 
>> send the document to the IESG before Montreal; if it is not, we have 
>> our agenda set out for Montreal.
>>
>> Harald, for the chairs.
>>
>> _______________________________________________
>> media-types mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
> 
> _______________________________________________
> media-types mailing list -- [email protected]
> To unsubscribe send an email to [email protected]


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