MEDIAMAN Working Group

Agenda IETF 115

Meeting: Tuesday, November 8, 2022 15:00 London (= GMT)
Duration: 1 hour
Chair: Harald Alvestrand

Introduction, Note Well, scribe, agenda bash (5 min)

Chair: Standard questions for each draft will be:
1) Who has read the draft?
2) Who supports going to Last Call at this time?
3) Who thinks there are issues that must be resolved before going to
Last Call?

Note that 2) and 3) are mutually exclusive

Principles for new Top Level types (10 min)

Presentation of draft-ietf-mediaman-toplevel (Martin Duerst): 5 min
(note: -01 will be the basis for discussion.)

Discussion (5 min)
Decision: Go for WG Last Call once issues are resoved, or await further
revisions?

Murray: None of the 3 drafts are using BCP 14 (Keywords) properly

Alexey: is there enough interest in documenting criteria (more clearly)

Chair asks the room if there should be an IANA list lof top level types.
One "why bother" from GK, but withdrawn after brief diuscussion.

Chair: needs to be revised again, not ready for last call.

Top level type "Haptics" (10 min)

Presentation of draft-ietf-mediaman-haptics (Muthusamy): 5 min

Discussion (5 min)
Decision: Go for WG Last Call once issues are resolved and -toplevel is
stable, or await further revision?

Yeshwant Muthusamy:

Coming from MPEG Haptics work in ISO/IEC 23090...

Intending to submit standards track RFC for "haptics" top level type.

Two sub-types to be included with the initial registration. Others are
mentioned.

Questions?:

Murray K: good to see checklist; mentions obsolete reference (1.1?);
(4.3) required parameters should be "n/a" not "none"; need security
considerations for subtypes (template requirement)

Harald A: (last slide) text not responsive to "toplevel" draft, but
could be replaced by "n/a"

Chair: seems to interest in getting this registered, with some
revisions.

Alexey: "Encoding Consideration: text/binary" is not syntactically
valid. It should be a choice
of "7bit", "8bit", "binary" or "framed". So I suspect the answer is
"binary".

Darrel Miller: about IVX
A: this is XML format, with alternative binary format

Chair: not ready for last call: issues to fix, dependency on "top level"
draft - but WG happy to proceed

Multiple suffixes for media types (10 min)

Presentation of draft-ietf-mediaman-suffixes (Manu Sporny): 5 min

Discussion (5 min)
Decision: Go for WG Last Call, or await further revisions?

Manu Sporny:

Multiple groups attempting to register media types with multiple
suffixes, but how to interpret these? This tries to answer that.

Repo is transferred to MediaMan WG.

Not much change since last draft. 4 issues raised:

1. request to add to security considerations about how suffixes might
   be abused. E.g., Can implementations to tricked into bypassing
   security checks?

2. Current text contrived ...?

3. Guidance around fragment processing - how to interpret fragment if a
   suffix is dropped. Asking for guiudance. E.g., Suggest it's OK to
   interpret json+ld oper JSON-LD spec, not per (JSON?)

4. What if... big media type... process according to more general
   spec... end up with unspecified media type (e.g. without
   serialization)?

Guidance now: if you choose to do this, must stop on reaching
unregistered media type. Text to be written.

1. Tedt T raised editorial issues and questions for clarification

Not yet ready for last call; more details to add in response to issues
raised; hopefully ready for LC by next IETF.

Questions?:

Darrel Miller: some suffixes are "different"; some add new layuer of
semantics, others change wire encoding; what effect on use of fragment
identifiers?

A: difficult case; if you do this, bets are off for fragment processing.
This could lead to (e.g.) security problems. "here be dragons"

Harald A: gzip is reversible transform: so should suffix registration be
the place to say what to do? This draft needs to say something about
this.

Alexey: (similar thought) Does this need update to the registration
template?

Harald will provide text to the list.

Chair: More work is needed on the draft, but seems to be on track. "Keep
up the good work"

Revision of registration procedures (15 min)

Introduction (Mark Nottingham) (5 min)
Discussion (10 min)

Wrapup, action items, followup (10 min)

Chair: charter allows registration procedures to be reviewed.

Mark Nottingham:

Seems some who could register media types don't; some find it too
hard; some aren't allowed to register what they want to. Suggestion to
oppen up procedures.

Further suggestion is to use GitHub for managing the registration
process. Github helps to maintain history and context, unlike simple
form submission to IANA. Suggests to keep the form, but could add
documentation, and to makle the process/progress more transparent.
Multiple submission initiation options are possible (e.g. email
submission, GitHub issue, ...).

Suggests Github works better as it alows faster iteration, doesn't
require IANA to be in the loop.

Other issue: standardss tree reserved for things considered standards.
Other options are second class options. Other registries don't use
trees; trees can give rise to renaming problems (like X- headers). Maybe
should be more open to, e.g., open source projects.

Maybe require more descritive (longer) names from projects?

Harald: reason for onerous process, so if two things have the same name
they should be the same thing ... therefore want a stable reference.

Graham: In regards to Open Source projects (using my experience in URI
reviews): widespread use can be a criteria that takes precedence over
the need to be a recognized SDO.

Also GK, things with same name being the same thing: isn't that an
argument for making registration easier?

Manu: also makes similasr point with respect to DID registrations. BUT,
perople without relevant knowledge often jump in and try to register
standards without reading required documents. Experts spend lots of
effort trying to explain rules and it stresses them. Also, problem of
"squatting" on a name.

Alexey: Let's just try Github process and see how it works. This doesn't
require any RFC update.
Also prefer to expand current definition of "SDO" to include well known
open source projects. This will require a small update to the Media Type
registration procedure RFC.

Mark: Maybe give experts more discretion and more guidelines.
Also maybe let companies use namespaces (e.g. "microsoft-").

Alexey: Namespaces are already recommend by the current RFC.

Graham: Tension between ease or registration and quality of submissions:
this is why we use provisional vs permanent registrations for message
headers and URI schemes.