Sarven isn't here.

FedCM update (1136):

Matthew: Discussed in Plenary last night, decided to have it in the agenda for today.

Lola: I remember I had to look at the comment.

Ehsan: I submitted my review last night, Jeffrey got some questions. So not ready yet.

Lola: Let me have a look.

Lola: They seem to they talk past you. They are not realising your concern about the three URLs. I do wonder about the top-level FedCM directly, if this is the case, what is the point of all of this?

Ehsan: My issue is the permission claim from the RP and then matching from the IdP. I believe there is a chance of injection or being malicious so all three items should be shown. This is authentication ceremony so better be crticial on all detail, show everything to the user and let the user decide.

Lola: It is healthy to be cautios as it is authentication. Let me look at your draft response.

Lola: I think Jeffrey's question is particularely potenant(??) on the attack is possible. Are you saying that the attack is possible?

Ehsan: ???

Lola: I think we need to frame that serious example, I think the attack likelihood is low so maybe opt in for accept with concern.

Ehsan: Maybe Serena can help?

Lola: Maybe phrase the question. "What instances show two URL's are shown? and why is that the case and why all three should be shown? anyone has problem?

Matthew: no othing from me. It would be a good idea to talk at TPAC with the people there. Will try to do that.

Sarven: On my todo. Will come back to this.

(Sarven isn't here today)

Sarven: Drafted a review at https://github.com/w3ctag/design-reviews-private-brainstorming/issues/215#issuecomment-3640921722 They want a review on a working draft. they are referring to their primer as their explainer. I think they weren't clear on the idfferences betwen RDF 1.1 and 1.2 concepts in abstract data model, but that's mostly editorial work. I suggested they bring some of the explainer material, especially changes, from the specific specs up to the higer concepts spec in the primer.

The only technical concern I had: as it stands, the mediaType that concrete RDF syntaxes has registered at IANA do not mention the optional parameter stuff that could be used, like the version. this group is trying to do: version 1.2, that needs to be parsed differently by consumers than RDF 1.1, so the version is a way of giving heads up to the consumer of how it should be processed. Because the original mediaType doesn't indicate the version, any existing 1.1 client/consumer would not observe what that version parameter would be. if there is a version information included as part of the document or payload, inline, then 1.1 parsers would fail, because that isn't valid 1.1.

The group is doing fine. They've done 1, with the n-triples format, so they're sending a submission to iana to update the mediaTypes to introduce an optional version parameter. I think they need to do that consistently for all specs, and they need to be more clear about how things should fail, error handling. As it stands, it's not clear how the error handling might be, so I'm suggesting that they work on that. It's a working draft, so it's not so bad right now, but one really needs to read the thing and juggle all the specs in parallel (RDF concepts abstract model, and then concrete syntaxes: JSON-LD, Turtle, etc. So the Concepts realise how the RDF is encoded.)

I'm suggesting this should be marked as satisfied. This particular document seems to be on the right track.

I'll look at the other ones in depth (RDF 1.2 semantics and RDF 1.2 n-triples), and will review those. But it's fine.

Hadley: for the future, if you find yourself doing research into other specs, it's fine to ask the submitters to put more into their explainer.

Sarven: ok

Marcos: Have they really verified the versioning thing with mime types? Unless they have done it very carefully? If x doesn't do it right, they may get themselves into a bad situation.

Martin: With mime types there should be negotiation

Sarven: they did highlight the negotiation in the spec. They did say how clients should approach unrecognised versioning. I agree with you, Marcos, that type of error handling or reccommendation for devs should jump out more. It's a working draft, so fine for where it is, but it needs more iterations.

Marcos: we shouldn't solve it for them, but it sounds a bit concerning, that they're getting into that situation.

Sarven: i'm not personally crazy about the direction this has taken with the versioning, but I'm not sure there is a lesser evil. They're introducting a new feature, the alternative was introducing a new media type. From the RFCs, the version is discussed there and it should only be used to clarify and add info to the current media type, not to signal new feature. Theyll ground that by updating the media type to bring the notion of an optional parameter like version type, which I think is acceptable. the alternative is worse.

Martin: In general if you change the media type in any way, that basically signals it is incompatible with the other thing, and lot of content negotiation would ignore versioning. So might as well define a new media type. Which is also true for version in-line. Media type determines the model so don't put version in media type and in content because there is already good

Marcos: that's what i heard too.

Martin: "the registration for the media types do not define the version parameter."

Sarven: the concrete ones are making an update to the registration. But I agree with you. Even the version: the parameter is only intended to clarify. If the turtle is saying 1.1, tha'ts fine, but you don't want to say 2.7 to hijack it as a new version. Updating the registration is the only safe and less breakage.

yves: I. agree with martin that if they are incompatible, it shoudl be a different media type to avoid issues. Is the format describing, and is there a way to do graceful degradation: is it compatible with previous version just missing one point, or do they need to update the processing of it becasue the changes are differet? If they ahve te capabiliteis of that, it's fine. If not, it's missing.

Sarven: they do, RDF 1.1 is still valid 1.2.

Martin: is RDF 1.2 valid 1.1?

Sarven: No. That's why you say the version. Fail the 1.1s early. For example, if a client were to include Accept, if they didn't include Accept, the server has the option to return with the version if they want to. If a client asks with a version, and the server accepts it, the conneg will figure it out.

Martin: So if I undestrand this correctly: 1.2 adds featurees that a 1.1 parser won't handle?

Sarven: yes

Martin: did 1.1 add a version on the media type?

Sarven: no

Martin: that's bad. the spec is bad on how you handle uknown parameters. It may treat the whole thing as an opaque stream, treating it as a different media type. The other way to interpret it: unknown parameters are ignored.

Sarven: does not change the core interpretation of the model. Providing additional info to signal, similart to the profile parameter. Will say what that payload is going to include.

martin: so you have a major interop problem. the 1.1 parser will throw away the version attribute, say "I know how to process this!" and fail in interesting ways, because it has 1.2 features. The only sensible thing to do is to get a new media type.

Sarven: they are being a bit, as I understand it, done some survey to understand the adoption of this and how ready the parsers will be able to migrate over. There is more nuance to this.

Martin: I understand. And they may think they can survey the full set of implementations. My experience with the web is that that is impossible. I think the only adivsable thing to do is to define a new media type.

Marcos: I agree.

Martin: the 1.2 parsers can understand both media types, 1.1 and 1.2.

Marcos: "you broke the thing, ti's fine, declare a new media type and be more careful in the future." We need to make that recommednation as the TAG, and they can go from there.

Hadley: do we have consensus on that?

Sarven: I'm 75% ok with what they say. They do have a note saying "clients should be prepared... consider downgrading the content."

Martin: is that text that only appears in 1.2?

Sarven: yes

Martin: but the 1.1 impelementations will be looking at the 1.1 spec.

Sarven: nobody uses old versions of HTML

Martin: modern borswers use the docType to agree that the content is HTML5, which is annoying and not a pattern I would recommend, which is why we have conneg and media types.

Sarven: How is CSS doing... it's using hte same media type. What does a 2.1 parser do when it encounters a CSS 4 payload?

Martin: I'm not sure, because thins like app support have added ne wthings. but they've relied on that the olde parsers do brace matching, which is sufficient to make sure the new content will cause the old content to choke. It's effectively a forward-compatible format. I'm hearing from you that RDF is not. Which is understandable. In that context, with a compatibility break, the sensible thing is to define a new media type.

Marcos: there is no versioning in CSS. there are levels

Martin: And the levels are not about the grammar. That grammar works in a CSS parser from 10 years ago. The features may not work, but it will parse. The rules that parser does understand will apply, so it degrades gracefully. Building a language that has that capability is a pain, and the CSS people that was important enough to do all that work. It's being authored by humans.

If RDF doesn't want to put the work in, which is a valid choice, it's a compatibility break between versions, and therefore they have different formats. That's ok.

Sarven: I don't disagree. Updating the media type is a valid path. So if updating means there are incompatbilites between the latest update with the prior version, then the web platform is itself permitting that.

Martin: but by retroactively putting requirements on implementaitons on the old spec, you're banking on the idea the at the implementations will be all updated in a reasonable timeframe. Every time we've tried to do that on the web, it's failed. Which is why we have those hacks in HTML.

Marcos: 15 years

Martin: after that point, we were much more cautious about how we were managing the format. Still ongoing, but the work is worthwhile.

Marcos: like all tags in HTML must have a closing tag. That is the compromise we made.

hadley: what are we going to do with this?

Sarven: If Martin and Marcos want to add/update the review i've made, that is a way we can move forward. Personally I'm ok with what they want to do

hadley: if we don't have consensus, we can share that, and explain. or keep discussing until we do.

Martin: our responsbility is to point out the risks. And suggest.

Sarven: I'll think about how to handle this. Martin/Marcos, if you could write something, that might help

Hadley: You also have the minutes from this discussion to pull from.

Sarven: Last draft review: https://github.com/w3ctag/design-reviews-private-brainstorming/issues/215#issuecomment-3663084744

Sarven: We agreed last time that a new media type is the right approach. I tried to integrate that into the proposed comment. I have acknowledged what they're doing, and considerations they've made, including the need to be aware of the effect on 1.1 parsers - and that a new media type would remove the potential misinterpretation.

... There's a whole other angle on the story, re the RFC. What I want to hightlight is that, what's happening with 1.1, how it handles syntax it doesn't recognise... all of that's already there. That part is not defined by these specs. 1.2 is not introducing something new to how 1.1s are behaving in practice. As far as 1.1 is concerned, 1.2 is unrecognized/unkown syntax, same as invalid data.

... Tried to write up the space and allow the group to make their decision from that point. I think "satisfied with concerns" is better than "satisfied". What do Martin and Yves think?

Hadley: Keen to hear from Martin and Marcos, and Yves if you have anything. Suggest we be appreciative and clear in our review, and ensure they know what the next steps are (i.e. if we close it, what is next).

Martin: Saren's key point here is to be aware of 1.1 implementations. In my opinion this is not the right approach, but it's their spec and they can live with the consequences of it. I don't think this is going to work well, though it could be a small ecosystem where there will be 1.1 parsers for a long time.

Yves: I discussed with team contact for RDF group, the need to have proper error-handling around versions, so the message is conveyed. OK with Sarven's comment.

Marcos; Nothing to add after last week. We are giving them fair warning, so they can make an informed decisiosn.

Hadley: Suggest you post and close.

Sarven: Thanks all.