Subject: [media-types] WG: IETF 112 agenda

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Nov 2021 13:31:29 +0100

Here's my proposed agenda for the meeting. (Apologies for the relative 
lateness!)

The structure is 5 min presentations / 10 min discussion / conclusions.

I hope the presenters can make it - otherwise we'll have to shuffle 
stuff around!

Harald

Agenda IETF 112

Meeting: Tuesday, November 9, 1430-1530 CET Duration: 1 hour

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

Principles for new Top Level types (15 min)

- Presentation of problem space (Harald): 5 min

- Discussion (10 min)

Top level type "Haptics" (15 min)

- Presentation of problem space (Muthusamy): 5 min

- Discussion (10 min)

Multiple suffixes for media types (15 min)

- Presentation of problem space (Manu Sporny): 5 min

- Discussion (10 min)

Wrapup, action items, followup (10 min)

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Nov 2021 13:38:46 +0100

I think that for the "haptics" and "suffixes" items, there is a decision 
to be taken:

Adopt the relevant draft as a WG draft Y/N?

With possible positions being "Yes, adopt now", "No, don't adopt (it's 
too wrong)", and "Do not adopt at this time (we're not there yet)".

On 11/3/21 1:31 PM, Harald Alvestrand wrote:
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Nov 2021 14:00:12 +0100

Correction: It's 1430-1530 meeting time, which is apparently 1530-1630 
CET. (I'm confused - thought Madrid was on CET).

---

From: Manu Sporny <[email-masked]>
Date: Sun, 7 Nov 2021 13:44:10 -0500

> - Presentation of problem space (Manu Sporny): 5 min

Slides for the topic above are attached to this email.

Google slides are here:

https://docs.google.com/presentation/d/1mAlCFvyWurUyViJqyKymnjKKZ-Br0srFCi1nTod_JKg/edit?usp=sharing

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 7 Nov 2021 22:54:09 +0100

I can imagine some more questions that can be raised about multiple 
suffixes:

- Is the namespace of suffixes itself a namespace (ie is there an unique 
definition of "+json" as a suffix)?

RFC 6838 sction 6 says "yes".

- Is the order of suffixes significant or meaningless (ie is vc+ld+json 
the same as vc+json+ld)?

Draft seems to say that the anwer is "significant", +ld+json must be 
registered, and this attaches no meaning to +json+ld.

- was suffixes a bad idea that we should abandon, attaching no special 
meaning to the + character?

The number of registrations in 
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml 
seems to indicate that even if it was true, it's too late to take this path.

---

From: Manu Sporny <[email-masked]>
Date: Sun, 7 Nov 2021 18:28:19 -0500

On 11/7/21 4:54 PM, Harald Alvestrand wrote:
> suffixes

All good questions, which you seem to have answered in a way that is aligned
w/ the current ID.

I didn't know about the the media-type-structured-suffix registry, and note
that +ld+json wasn't registered for JSON-LD... but probably should be?

I don't know if we have to write anything more to do that, though... it's
something to dig into to make sure RFC6838 is clear that you can register both
+json and +ld+json as a structured syntax suffix.

Harald, do you want me to add a slide that includes your questions for
discussion time? 10 minutes might be too short and we might want to handle
those via the mailing list and via the Github issue tracker?

-- manu

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Nov 2021 14:09:34 +1100

> On 8 Nov 2021, at 10:28 am, Manu Sporny <[email-masked]> wrote:
> 

The ability to do so was what I thought this session was about. Note that 6838 defines structured suffixes in terms of 'the final + in a subtype name' -- so it's questionable as to whether you can include a '+' in a structured suffix right now.

Have you considered just registering '+ldjson'?

> those via the mailing list and via the Github issue tracker?

FWIW, I think Harald has hit upon many of the central questions, and we should focus on them in the time we have.

Another is that 6838 describes the use case for suffixes as 'well-known structuring syntaxes' -- whereas linked data is a data model, not a syntax. While there's some fuzziness in this area, it might be good to talk about whether linked data is a 'structuring syntax' or something else.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Manu Sporny <[email-masked]>
Date: Mon, 8 Nov 2021 09:00:00 -0500

> Have you considered just registering '+ldjson'?

Yes, we did think of registering "+jsonld" back in 2013 and, IIRC, were
instructed by IANA folks to just do "ld+json" since it was a JSON syntax with
added semantics.

This was further reinforced in JSON-LD 1.1, where they took up the question
again, I think engaging w/ the registry maintainer (I wasn't a part of that
discussion, so I don't know the details), considering if "+jsonld" should be
registered... and deciding that it would cause too much chaos to register both
"+ld+json" and "+jsonld" -- possibly breaking implementations out in the field.

Fast forward 6+ years and we have other media types that use "ld+json" to
encode themselves, and people wanting to use the media type to decide how to
process the documents and thus things like "vc+ld+json" and "did+ld+json" were
born... but when we tried to register them, the experts said "Umm, we're not
sure how to interpret that extra '+'."

> FWIW, I think Harald has hit upon many of the central questions, and we 
> should focus on them in the time we have.

I'm fine w/ taking the conversation in whatever direction folks want to take it.

> Another is that 6838 describes the use case for suffixes as 'well-known 
> structuring syntaxes' -- whereas linked data is a data model, not a syntax.
> While there's some fuzziness in this area, it might be good to talk about
> whether linked data is a 'structuring syntax' or something else.

It's an abstract data model that is formally described in:
https://www.w3.org/TR/json-ld11/#data-model

It's not a structuring syntax.

Some have wondered why it's not "ld+vc+json"... and the answer there seemed to
be "because the Verifiable Credential isn't encoded in JSON... it's encoded in
JSON-LD"... the structure needs to go from most specific to least specific...
noting that the earlier parts of the media type describe data model-y things
and the latter parts of the media type describe syntax-y things.

It's a reasonable mental model, if not a bit fuzzy when it comes to components
in the middle.

-- manu

---

From: Ned Freed <[email-masked]>
Date: Mon, 08 Nov 2021 15:50:44 -0800 (PST)

> RFC 6838 sction 6 says "yes".

And so does the current draft, albeit in a different way: It draws an
equivalence between all of the possible sufixes and a correspnding media type.
So a trailing +json is necessarily associated with application/json,
+ld+json with both application/ld+json and application/json, and so on.

I wish we're considered using this approach when we first specified suffixes.
It might have made things clearer.

> registered, and this attaches no meaning to +json+ld.

It's an unavoidable consequence of the way the mechanism is defined, but it
should be stated explicitly.

> seems to indicate that even if it was true, it's too late to take this path.

And the fact that we (intentionally) haven't registered any media types with
multiple +'s in the name means it's possible to redefine the meaning of
multiple +'s as long as it doesn't break existing single +suffix usage. (And
I see no reason why it should.)

Of course it's possible there are unregistered media types with multiple +s
in the name in use. But if there are, it only really matters if the suffix
components are things that should be registered *and* the usage differs
from what we specify. I think that's unlikely.

				Ned