IETF
mediaman
mediaman@jabber.ietf.org
Tuesday, November 9, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[00:16:04] Glen joins the room
[00:16:08] Glen leaves the room
[14:05:56] Meetecho joins the room
[14:15:03] Yeshwant Muthusamy_web_245 joins the room
[14:15:03] Harald Alvestrand_web_165 joins the room
[14:17:46] Alessandro Amirante_web_723 joins the room
[14:18:29] <Harald Alvestrand_web_165> testing
[14:18:31] Ching-Heng Ku_web_142 joins the room
[14:18:34] <Harald Alvestrand_web_165> @meetecho ayt?
[14:19:13] alexamirante joins the room
[14:19:24] <Meetecho> Hi Harald, yep
[14:19:35] <Meetecho> Any problem?
[14:20:22] <Harald Alvestrand_web_165> can I present the slides that are preloaded under meeting materials?
[14:20:30] <Harald Alvestrand_web_165> (PDF)
[14:21:09] <Harald Alvestrand_web_165> currently presenting from another tab instead
[14:21:16] <alexamirante> you need to first do "manage slides" from the setting menu (upper-right corner of the UI)
[14:22:14] <Harald Alvestrand_web_165> OK thanks!
[14:28:04] Mark Nottingham_web_936 joins the room
[14:28:13] Dave Thaler_web_875 joins the room
[14:28:22] Mark Nottingham_web_936 leaves the room
[14:28:26] Mark Nottingham_web_442 joins the room
[14:28:27] Dave Thaler_web_875 leaves the room
[14:28:31] Dave Thaler_web_500 joins the room
[14:29:09] Manu Sporny_web_385 joins the room
[14:29:13] Manu Sporny_web_385 leaves the room
[14:29:15] Manu Sporny_web_342 joins the room
[14:29:41] alexamirante leaves the room
[14:30:04] mnot joins the room
[14:30:09] Amanda Baber_web_989 joins the room
[14:30:37] Cullen Jennings_web_272 joins the room
[14:31:08] tim costello_web_926 joins the room
[14:31:23] Jonathan Lennox_web_683 joins the room
[14:31:31] Chris Wendt_web_204 joins the room
[14:31:58] Chris Ullrich_web_954 joins the room
[14:31:59] Phillip Hallam-Baker_web_562 joins the room
[14:32:12] Alexey Melnikov_web_262 joins the room
[14:32:26] Renan Krishna_web_444 joins the room
[14:32:36] Alexey Melnikov_web_262 leaves the room
[14:32:40] Alexey Melnikov_web_531 joins the room
[14:34:22] <Phillip Hallam-Baker_web_562> I can scribe
[14:34:34] Phillip Hallam-Baker_web_562 leaves the room
[14:34:38] Phillip Hallam-Baker_web_617 joins the room
[14:34:55] Phillip Hallam-Baker_web_617 leaves the room
[14:34:59] Phillip Hallam-Baker_web_840 joins the room
[14:35:20] Phillip Hallam-Baker_web_840 leaves the room
[14:35:24] Phillip Hallam-Baker_web_260 joins the room
[14:35:26] Ned Freed_web_265 joins the room
[14:38:46] Toerless Eckert_web_831 joins the room
[14:38:51] alexamirante joins the room
[14:38:57] <Alexey Melnikov_web_531> Somebody asked to register a new model/* media type just recently
[14:39:26] <Alexey Melnikov_web_531> I.e. in the last 6 months. model/* is rare, but apparently still used.
[14:39:28] Toerless Eckert_web_831 leaves the room
[14:39:49] Murray Kucherawy_web_936 joins the room
[14:41:05] David Schinazi_web_762 joins the room
[14:41:28] <mnot> Cullen makes a really good point — and it calls into question yet again what the actual value of structured suffixes are
[14:41:53] David Schinazi_web_762 leaves the room
[14:41:55] <Ned Freed_web_265> FWIW, there have been subtypes registered under multiple top-level types, and not just for RTP.
[14:42:23] <Alexey Melnikov_web_531> I think removing top level types would be too late at this point
[14:42:23] <Jonathan Lennox_web_683> But are they actually the same format, just with different top-level characteristics?  Not name collisions?
[14:42:41] <Ned Freed_web_265> Same format, different use.
[14:43:26] alexamirante leaves the room
[14:44:03] alexamirante joins the room
[14:44:19] <Ned Freed_web_265> PHB is of course correct. Knowing the general nature of a type is useful. It's not limited to browsers either - email systems have been known to filter based on top-level types.
[14:44:21] <Alexey Melnikov_web_531> IMAP has a separate field for type and subtype.
[14:44:44] <Alexey Melnikov_web_531> Indeed, email systems have different handling based on top level type
[14:45:39] <Cullen Jennings_web_272> I think the content inspection tools are sort of disappearing with TLS everywhere
[14:45:51] alexamirante leaves the room
[14:45:52] <Ned Freed_web_265> It's also useful from the practical standpoint of people knowing from the name what sort of type it is. Frankly, I think this is the most important case by far.
[14:46:44] Emiliano Spinella_web_777 joins the room
[14:47:03] <Ned Freed_web_265> As for content scanning, no sensible content scanning system bases any sort of decision on the untrusted content type. It might check to see if the type is intentionally misleading, but that is it.
[14:47:56] <Dave Thaler_web_500> @Cullen some content filters are above TLS (like browser extensions).  No idea if they use TL media types.
[14:48:43] <Cullen Jennings_web_272> All good points but if we have no idea who uses TopLevelTypes, we are going to have no idea how to set up the correct properties of it
[14:49:03] <Dave Thaler_web_500> agree
[14:49:32] <Ned Freed_web_265> Cullen: The world doesn't consist solely of unrestricted HTTP connections. Email is the obvious counterexample where content scanning is commonplace.
[14:51:07] <Ned Freed_web_265> Wrong wrong wrong wrong wrong.
[14:51:17] <Alexey Melnikov_web_531> Cullen: not true!
[14:51:37] <Ned Freed_web_265> Cullen, everything you just said is nonsense, top to bottom, side to side.
[14:51:43] <Dave Thaler_web_500> I do know there is a common perception (real or imagined I don't know but someone here probably does) that browsers use the existing TL types, e.g., whether to display content on screen (even if it doesn't recognize subtype) or as a file.  Not sure that helps say anything about future ones.
[14:51:55] <Cullen Jennings_web_272> Ahgg, I totally defer to Ned and Alexey on this - I am sure they are right not me
[14:52:03] <Phillip Hallam-Baker_web_260> What about macros? That is the real test
[14:52:17] <Jonathan Lennox_web_683> Is that a special characteristic of multipart, though?  Do any other top-levels have that property?
[14:52:43] <Alexey Melnikov_web_531> Multipart, text and possibly message
[14:53:48] <Alexey Melnikov_web_531> My web mail client also handles "image" and "audio" differently, because it generates different HTML for them
[14:54:26] <Phillip Hallam-Baker_web_260> The real concern for firewalls is active content. And you can have that in any media type. Fonts can be programs.
[14:54:48] <Alexey Melnikov_web_531> PHP: that is certainly true
[14:55:22] <Jonathan Lennox_web_683> I.e. you assume any image/* can go into an <img> and a web browser can handle it?  (Or at least there's no better way it could be handled?)
[14:55:45] <Jonathan Lennox_web_683> Hm, tag stripping.  Can go into an %lt;img>
[14:55:51] <Alexey Melnikov_web_531> Yes.
[14:56:37] <Ned Freed_web_265> Absolutely. Active content was recognized from the start as the main danger. Our attempts to deal with it, e.g., safe TCL, were naive at best.
[14:56:45] <Alexey Melnikov_web_531> And audio/* can be &lt;audio> element, etc
[14:57:20] Emiliano Spinella_web_777 leaves the room
[14:57:40] <Phillip Hallam-Baker_web_260> I think it will probably help folk work out what the format is about if it is called haptics/whatever rather than application/whatever
[14:57:42] Lee-Berkeley Shaw_web_977 joins the room
[14:57:58] <Alexey Melnikov_web_531> Indeed
[14:58:49] Lee-Berkeley Shaw_web_977 leaves the room
[14:59:12] <Ned Freed_web_265> PHB: Agreed.
[14:59:42] <Murray Kucherawy_web_936> +1
[15:00:29] <Phillip Hallam-Baker_web_260> Summary of discussion so far: 1) The use of toplevel names does not give rise to critical concerns, 2) Filing these new formats under haptics will be more convenient going forward.
[15:00:51] <Ned Freed_web_265> Can these haptics streams be bidirectional? Or are two streams used when you want feedback?
[15:01:05] <Murray Kucherawy_web_936> Does (1) mean "the creation of new names is not a concern"?
[15:02:18] <Alexey Melnikov_web_531> +1. I am fine with haptics at a new top level
[15:02:57] <Chris Ullrich_web_954> Ned, the current haptic formats don't specify any sensing/tracking data. This may happen in MPEG-I Phase 2 but we're a few years out on that.
[15:03:00] <Cullen Jennings_web_272> gcode is uh, not really code in my mind in that it is not even close to turning complete. But postscript is ....
[15:03:15] <Jonathan Lennox_web_683> I'd say "a new name is not a concern for media types which otherwise would have to go under application".  That's the "we can't have any special treatment for this" category so a new toplevel would be handled the same for devices that don't know the top level.
[15:03:21] <Ned Freed_web_265> PHB: More generally, I find the cost-benefit basis people seem to be using to be skewed from reality. Speaking as a type reviewer and implementor of code to support various types, the creation of a new top-level type is pretty much a nothingburger.
[15:03:52] <Murray Kucherawy_web_936> So we're fine with this new top-level domain, and just need to look at the more general policy/guidance.  Do we want to approve this one and then set up the guidance document, or vice-versa?
[15:04:10] <Dave Thaler_web_500> To Jonathan's point in chat about image maybe being auto-put into an img html tag, if we start seeing haptics html tags then having a haptics TL type would probably be helpful.
[15:04:12] <Murray Kucherawy_web_936> sorry, top-level type, not top-level domain.
[15:04:14] <Ned Freed_web_265> We go on and on about the benefits not being sufficient. But the costs are so low!!!
[15:04:33] <Alexey Melnikov_web_531> Murray: I am happy to approve this one and then think about generic guidance.
[15:04:43] <Cullen Jennings_web_272> The MP4 example highlights how totally irrelevant the top level is.
[15:06:21] <Dave Thaler_web_500> mp4 is a sort of multipart itself...
[15:06:27] <Alexey Melnikov_web_531> Murray: I don't want to delay "haptics" and as Ned said the risk of creating a new top level one is low
[15:06:36] <Ned Freed_web_265> First, the fact that there are types that can fit under multiple top levels doesn't make them irrelevant.
[15:07:00] <Alexey Melnikov_web_531> "mp4" as a new top level type ;-)?
[15:07:22] <Ned Freed_web_265> Second, top level types for things like mp4 have been used as an indicator of how mp4 is being used.
[15:07:24] <Phillip Hallam-Baker_web_260> MP4 with active code.
[15:07:28] <Murray Kucherawy_web_936> Last time I read the draft it looked like it was generally in good enough shape to adopt.  I might like a section on guidance about what the reviewers should be looking for in future registrations.
[15:07:42] <Phillip Hallam-Baker_web_260> Some of the stuff in my basement,
[15:07:43] <Cullen Jennings_web_272> Well once again, mp4 is another disaster as we treat it as a media type but it actually a container type
[15:08:02] <Jonathan Lennox_web_683> But "multipart/mp4" would also be a disaster.
[15:08:33] <Cullen Jennings_web_272> What we actually need is a container type and, the media types inside them
[15:08:35] <Ned Freed_web_265> Third, the problems with generic stream container types like mp4 don't begin or end with the top level type. There are all sorts of subtype issues as well, with registrations of specific profiles.
[15:08:38] <Alexey Melnikov_web_531> Dave: exactly
[15:08:40] <Cullen Jennings_web_272> for example
[15:08:53] <Cullen Jennings_web_272> mp4/h264+opus+hapticType22
[15:09:14] <Dave Thaler_web_500> thanks, this is a technical reason to have a TL type, in my view
[15:10:47] <Ned Freed_web_265> PHB: An example of MP4 with code is when subtitles streams are included. Some of them allow for pretty sophisticated positioning control.
[15:11:31] <Phillip Hallam-Baker_web_260> @ned agreed. Also Llama dalek's controls (behind me in the video)
[15:12:03] <Jonathan Lennox_web_683> When MPEG4 was first introduced I remember a presentation saying you could encode a full mixdown from MIDI source to final audio in MPEG4, but I don't know if that survived in real life.
[15:12:04] <Phillip Hallam-Baker_web_260> @ned, if there is an intruder, he reacts by 'playing' a script.
[15:13:15] <Ned Freed_web_265> Dangers abound...
[15:13:34] <Murray Kucherawy_web_936> I have no objection to allowing it as long as we can agree on an interpretation of it is non-ambiguous.
[15:13:42] <Murray Kucherawy_web_936> that is*
[15:13:58] <Alexey Melnikov_web_531> I find +xml+zip more compelling
[15:14:10] <Ned Freed_web_265> Non-ambiguous and no conflict with previous interpretation
[15:14:10] <Alexey Melnikov_web_531> than +ld+json
[15:14:26] <Murray Kucherawy_web_936> Ned: Right
[15:14:30] <Phillip Hallam-Baker_web_260> Got to allow structure
[15:14:46] <Phillip Hallam-Baker_web_260> What is the media type though? The wrapper?
[15:15:26] <Murray Kucherawy_web_936> Right now I believe everything before the first + is the type/subtype, everything after the first + is a single suffix
[15:15:46] <Murray Kucherawy_web_936> But that last bit is mushy
[15:16:13] <Alexey Melnikov_web_531> Murray: If you application understands suffices ;-)
[15:16:18] <Murray Kucherawy_web_936> right
[15:16:25] <Ned Freed_web_265> Actually, no. We keyed it on the last +, not the first. Everything before the last + is not a suffix.
[15:16:53] <Phillip Hallam-Baker_web_260> type names should be processed left to right.
[15:17:02] <Phillip Hallam-Baker_web_260> vc should be controlling first
[15:17:04] <Phillip Hallam-Baker_web_260> then ld
[15:17:06] <Jonathan Lennox_web_683> I don't imagine suffix-parsing implementations are very consistent on this.
[15:17:07] <Phillip Hallam-Baker_web_260> then jscon
[15:17:20] <Murray Kucherawy_web_936> Jonathan: I think yeah that's the problem
[15:17:32] <Ned Freed_web_265> But since we never allowed a media type with a + in the subtype name (with one bizarre exception where it's the last character) and never allowed a suffix that contained a +, I don't think there's a problem changing the definition of a second +.
[15:19:45] <Murray Kucherawy_web_936> I think order should have meaning.  Personally I think consuming suffixes right-to-left is the way to go.
[15:19:46] <Ned Freed_web_265> JL: I have no doubt that they are inconsistent in whether they look at the first or last + - even though the spec told them what to do - but again I don't think it matters. Either way they won't fail in some sort of ugly way.
[15:19:51] <Alexey Melnikov_web_531> I will have a problem with order not being significant
[15:20:08] <Jonathan Lennox_web_683> Order should be significant, especially for an example like +xml+zip
[15:20:19] <Alexey Melnikov_web_531> Exactly
[15:20:21] <Dave Thaler_web_500> right, as long as order is significant, I like it.
[15:20:32] <Ned Freed_web_265> Order has to be signficiant to maintain backwards compatibility, and it has to be that the last suffix is the outermost thing in the type.
[15:21:05] <Murray Kucherawy_web_936> Yeah, I think that matches what I'm envisioning.
[15:21:15] <mnot> If by 'significant' people mean that the specific suffix (e.g., ld+json) needs to be registered, I agree.
[15:21:26] <Alexey Melnikov_web_531> mnot: yes
[15:21:33] <Ned Freed_web_265> mnot: +1
[15:21:33] <Murray Kucherawy_web_936> What about registering "ld" and "json" separately?
[15:21:54] <Alexey Melnikov_web_531> This would be much harder to deal with
[15:21:56] <Murray Kucherawy_web_936> Should we have to register "ld+json" and "json+ld" separately?  Or just register the tokens and let the order spell out the process.
[15:22:01] <Dave Thaler_web_500> In the example on screen there is no value to registering "ld" separately
[15:22:05] <mnot> Then a registry entry could define 'application/foo+json+ld' which is going to be a problem
[15:22:05] <Jonathan Lennox_web_683> I don't think there's any meaning to "ld", the thing is "JSON-LD".
[15:22:13] <Dave Thaler_web_500> since +ld (vs +ld+json) doesn't mean JSON-LD
[15:22:15] <Murray Kucherawy_web_936> maybe that's a bad example
[15:22:34] <Cullen Jennings_web_272> I think we register 3 things here. Json, ls+json, vc+ld+json
[15:22:45] <Ned Freed_web_265> Cullen: +1
[15:22:45] <Murray Kucherawy_web_936> I'm just thinking foo+xml+zip means "unzip it", "unxml it", now you have a "foo".
[15:22:58] <Cullen Jennings_web_272> is there was an xml version of vc, then there could also be vc+xml
[15:23:00] <Murray Kucherawy_web_936> So those could all be separate things, rather than registering specific combinations.
[15:23:12] <mnot> Cullen +1 (in different registries)
[15:24:01] <Alexey Melnikov_web_531> Suffixes are already in a separate subregistry.
[15:24:15] <Ned Freed_web_265> If you make them separate, then you open the door to things like ld+ber or ld+xml. Do we really want this?
[15:24:30] <Alexey Melnikov_web_531> Ned: no.
[15:24:36] <Jonathan Lennox_web_683> If someone wants to register them, but they'd need to be registered explicitly.
[15:24:37] <Murray Kucherawy_web_936> Yeah or "zip+xml".  wut.
[15:24:52] <Jonathan Lennox_web_683> ld+cbor seems like it might be useful to someone
[15:25:15] <Cullen Jennings_web_272> removing myslef from Q as I was going to say what mnot said
[15:25:18] <Cullen Jennings_web_272> +1 mnot
[15:25:28] <Manu Sporny_web_342> Yes, what @Mark said... I believe that's ONE of the things that the current draft is suggesting... clarify that structured suffixes can contain '+' character. I think DID WG and VC WG would be fine w/ just saying "structured suffix can contain + character".
[15:25:57] <Dave Thaler_web_500> does application/foo+zip necessarily mean that unzipping results in an application/foo?
[15:26:05] <Ned Freed_web_265> I think we need to do a little more than say +s are allowed in suffixes. I think the current draft has this right in mapping trailing sufix sequences to separate media types.
[15:26:30] <Murray Kucherawy_web_936> @Dave: That's always how I've naturally parsed it.
[15:26:53] <Manu Sporny_web_342> @jonathan -- ld+cbor -- There is work on CBOR-LD here -- https://docs.google.com/presentation/d/1ksh-gUdjJJwDpdleasvs9aRXEmeRvqhkVWqeitx5ZAE/edit
[15:26:54] <mnot> That's a processing model. It doesn't apply to everything - e.g., ld
[15:27:09] <Ned Freed_web_265> @Dave: Yes, but realize that application/foo may have no actual representation associated with it.
[15:28:04] <Jonathan Lennox_web_683> I think application/foo+zip means "you can feed this to a zip parser and get something valid out", but by definition with zip it can be multiple files.
[15:28:29] <Dave Thaler_web_500> that seems to prevent +zip suffix from being used for zip archives containing multiple "files", or am I missing something?
[15:28:37] <Jonathan Lennox_web_683> So which one would be the application/foo is poorly defined.
[15:29:04] <mnot> I am assuming that adopting these drafts doesn't necessarily correspond 1:1 with publishing RFCs
[15:29:05] <Ned Freed_web_265> There are types using the +zip suffix with multiple "files" inside.
[15:29:54] <Dave Thaler_web_500> yes, Ned that's my point...  so the expectation about foo+zip unzipping to foo is suspect to me
[15:29:54] <Manu Sporny_web_342> Thanks all :)
[15:29:54] Murray Kucherawy_web_936 leaves the room
[15:30:01] tim costello_web_926 leaves the room
[15:30:02] <Alexey Melnikov_web_531> Thank you all
[15:30:05] <mnot> g'night
[15:30:13] <Yeshwant Muthusamy_web_245> thanks all!
[15:30:15] Alexey Melnikov_web_531 leaves the room
[15:30:17] Harald Alvestrand_web_165 leaves the room
[15:30:19] Jonathan Lennox_web_683 leaves the room
[15:30:31] <Ned Freed_web_265> You're assuming there's a representation of "foo" as a single entity. That may not be the case.
[15:30:35] Chris Ullrich_web_954 leaves the room
[15:30:38] Cullen Jennings_web_272 leaves the room
[15:30:49] Mark Nottingham_web_442 leaves the room
[15:30:52] Ching-Heng Ku_web_142 leaves the room
[15:30:56] <Dave Thaler_web_500> agree, it may or may not be the case.   Unless we explicitly disallow it.
[15:30:58] mnot leaves the room
[15:31:02] Phillip Hallam-Baker_web_260 leaves the room
[15:31:11] Renan Krishna_web_444 leaves the room
[15:31:13] Manu Sporny_web_342 leaves the room
[15:32:03] Chris Wendt_web_204 leaves the room
[15:32:14] <Dave Thaler_web_500> (I have a pending media type request where I think the answer matters, to know if the subtype is correct or needs to change before registration)
[15:32:31] Ned Freed_web_265 leaves the room
[15:33:40] Meetecho leaves the room
[15:33:45] Yeshwant Muthusamy_web_245 leaves the room
[15:33:45] Dave Thaler_web_500 leaves the room
[15:33:45] Amanda Baber_web_989 leaves the room
[15:33:45] Alessandro Amirante_web_723 leaves the room