💯 On Fri, Nov 17, 2023, 14:47 David Waite <david= 40alkaline-solutions....@dmarc.ietf.org> wrote:
> 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 > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
