wMy concern is higher level, that we may be promoting over-expression of types.
My interpretation of historical decisions/retconning was that +xml made sense because XML documents form an object model that can be processable independently of the document. For the example of SVG data in an XHTML document, without a media type you could still understand that the document contained XHTML because of the namespaced root element. You could also understand the SVG data even without knowledge of XHTML. There is both an expectation that application/xml could be interpreted as XHTML by supporting tools, and that there was value in generic XML processing even without understanding the media type. Data expressed in the multiple RDF formats are similar to the XML case above - for a graph or subgraph, there are defined predicate relationships that could be understood outside the given context. An example would be W3C verifiable credentials - I can subject relationships in a credential without understanding what a verifiable credential is, because existing types and predicates may be in use. For JSON on the other hand, there is no expectation of universal consistency - there are only heuristics to attempt to interpret the data outside of context. We use suffixes for a second purpose - to group related media types together when they ‘only’ differ by format, e.g. application/calendar+xml and application/calendar+json For multiple suffixes, I might make a case that something like +rdf+xml provides value in that even without knowledge of RDF processing, RDF XML is still namespaced and there is the possibility of interpreting the contents of the document via XML tooling. I’m not sure +ld+json provides the same value, as there is no name spacing or other application/json rule that would provide an interpretation of the media as a generic type. The processor of that media would need still need context in order to process the data, and if they have the domain knowledge necessary to have that context they could just deal with the fully expressed media type. -DW > On Nov 17, 2023, at 11:03 AM, Orie Steele <orie@transmute.industries> wrote: > > Alexey Melnikov and I had a chat about > https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes > <https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/> > > I am sharing a summary of our discussion for the benefit of the list, > obviously this was just a discussion, and the media types working group will > need to decide if or how to address any of these topics. > > Regarding media type parameters, there should be no automatic inheritance. > > There can be parameters that come from the top level, the subtype, the first > structured suffix, or the last structured suffix. > > An interesting parameter to consider would be "profile" which is common. > > There should be commentary on media type parameters, especially regarding > cases where: > > application/ld+json and application/json might both have chosen to register a > common parameter name, such as "charset" or "profile". > > +ld+json seems to be fine. > > +jwt is confusing, since it's ambiguous which part, the header, payload, or > signature will be passed along. > > The validation rules here, are also problematic, in that they don't directly > address this case: > > https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-suffixes-06#section-2.5.1 > > We think the ambiguity here could be resolved, for JWT or CWT, the payload is > the natural part that is relevant, and this aligns with the current intended > use case within W3C. > > For example, W3C specs current request registration of: > > typ: application/vc+ld+json+sd-jwt > cty: application/vc+ld+json > > Where decoding the payload produces application/vc+ld+json. > > We should comment on this explicitly and warn implementers planning to use > multiple suffixes with: > > +jwt > +cwt > <>+sd-jwt <> > +jose > <>+cose > > ... or future similar structured suffixes... > > To do their best to conform to this behavior, or explain why they deviated > clearly, in their registration request. > > An alternative recommendation might be to flatten the suffixes, when pairing > with envelope content types, for example: > > application/vc-ld-json+sd-jwt > > This would also reduce unnecessary registrations, and simplify the guidance > to designated experts regarding subtypes > with multiple structured suffixes that are each envelope formats (for > example, +cwt / +jwt) <> > > When flattening is not an option, we recommend registering all suffixes, to > ensure consistency, safety checks, and to be explicit over implicit. > > For application/vc+ld+json+jwt and application/vc+ld+json+sd-jwt this would > mean registering: > > for application/vc: > > - +ld > <> > - +ld+json > > - +ld+json+jwt > - +json+jwt > > - +ld+json+sd-jwt > - +json+sd-jwt > > Some of these registrations could be made with a warning, saying, do not use > at this time. > > On the section regarding adjudication of registrations on the same subtype, > for the case where: > > application/vc+ld+json is registered and the change controller is W3C. > > https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-suffixes-06#section-2.3 > > We feel that the designated expert should have the ability to overrule the > change controller, but that their decision should be appealable to IESG. > > We should reach out to IESG regarding this proposal in case they have > comments. > > We think the common case will be that the designated expert will consult the > change controller, and agree with their position, > in the case the designated expert feels there is some unreasonable position > being taken by the change controller, > they should be allowed to overrule the change controller, and that decision > should be appealable. > In the case of W3C, this would likely involve working with W3C Liaisons and > the IAB as well. > > In the case of other organizations, it might be helpful to be able to consult > the IESG on the best course of action. > > In the case that the designated expert agrees with the change controller, the > registrant should seek a non conflicting subtype, > for example vc2, or a flattened subtype, for example vc-ld-json > > We discussed content formats, and we don't think there are any issues with > that registry, and the approach taken by multiple suffixes. > > In summary, I think the main item remaining is the guidance on "skipping > registrations" or "flattening" or "registering and recommending against use". > > This was also the last comment on the topic during the session at IETF 118. > > My personal preference would be to recommend the following to the group, > regarding intermediate suffixes: > > 1. flatten whenever possible. > 2. register and recommend against using. > 3. skip registration and deploy without considering interpretation of > intermediate suffixes. > > Alexey, please correct anything I miscommunicated. > > Regards, > > OS > > -- > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > <https://transmute.industries/> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
