Mediaman minutes - IETF 113 Vienna

Chair: Harald Alvestrand
Notetaker: Robert Stepanek

draft-duerst-mediaman-toplevel

• barry, alexey: rather keep standards track for new top-level definitions
• murray (chat): agree as well

Adopt or not adopt?
- harald: WG now to decide

Media Type registry:
- barry already have one
- alexey: subtle issue: there is no creation of top-level registry. defining new top-level types is tricky and time-consuming
- martin: question if we add or use existing is semantic issue
- barry: e.g. for "chemical" IETF is not in position to define, we are missing the experts. why not skip the whole standards track and let experts for media type decide?
- alexey: as media type expert hat on, sometimes experts need help. don't mind register procedure, specification has to be written. an expert can request review from IETF (barry +1)
- alexey: should adopt

• alexey: comment for top-level media type: if all subtypes have shared property restriction (e.g. "text" subtypes must have CRLF line endings, similar "multipart") that might be a criteria to define a top-level

• phil: should adopt. Everyone should be able to register media type, but for top-level standards track should be required

• john: standards track needs two things: media type reviewers do great job, but are not experts for top-level types. inform IESG is valuable contribution to process.

• murray: also support standards track. as media type reviewer it is good to not mistakenly make error and have wider review

Decisions

• harald: consensus to adopt. strong opinion for using standards track as gating criteria for new types. no reason to poll, confirm on list.
• barry: good with decision, but make sure to discuss it

draft-ietf-mediaman-haptics

• martin: great to compare haptics proposal with criteria for top-level type, but be careful to know who is dog and tail. draft-duerst-mediaman-toplevel is not to define the only criteria and new type just has to comply, it's the other way round to argue.
• phil: whole haptic field needs quite some expertise, avoid ambiguity, multiple code points in specification. this is not like application, where everything is different. rapdi changing environment, moving into its own type makes sense
• murray: defining both the standards track doc how to define top-level type and defining new type in parallel is good and running weel
• john: careful to not invent too much procedure. decisions on how to review are largely based on who know's something about it.
• harald: decision whether to allow for multiple reviewers is for discussion

Decisions

• harald: no reason heard why haptic is a bad idea. Wait a little for any process changes so that we can move draft forward.

draft-ietf-mediaman-suffixes

• harald: speaking as participant, the fibbing attack has been successful for bypassing virus check over email. security section needs to explicitly say when unpacking security must be taken at all levels (e.g. gzip bomb). can't blindly unpack stuff.
• john: when 5090 recollection is that structured subtypes was considered, not parameters. concern: walking path from one suffix to suffix is getting ambiguous
• martin: not totally clear if registry of suffix combination is required or not? do subtypes import fixed list of suffix combinations that they can be used with?

Decisions

• harald: please review this document and send comments
• harald: question of what needs to be registered is key. might have to register all legal combinations, or just the suffixes? or some alternative? is text/plain+gzip legal? at the moment is not, but will it be after this draft is published? doc has to give clear answer

Other

• harald: if open rfc6038 for discussion, should drop mac file types?
• martin: already update in progress, but not revision
• alexey: defer to ned on this, he is currently not availabke
• pete: afaik mac file types are completely deprecated on the mac. uses file extension types. maybe legacy support still? no point having them on the form
• barry: think this has gone with OS X
• pete: agree, might have existed in early OS X. deprecate them and put some notes in the form

Action items:

• harald: top-level document should be adopted by working group
• harald: strong indication that doc should say standards track is an appropriate level to require