Meeting Agenda : 2020-09-20
Intl.MessageFormat - WG Meeting
Time: 18:30 CEST - 9:30 PDT
Meeting Notes :Link
Call : Link
Agenda
- Formatting function signatures #190
- Roadmap #191
- Contribution Guide - How we evolve the spec document
I have prepared a presentation for the "Formatting function signatures" agenda item.
@mihnita Did I understand right that you were going to add here your summary of my presentation from yesterday? Or is that somewhere else?
For tomorrow's agenda: It would appear that we need to clarify what "data model" means. I thought it described a data-only structure holding message data, but @mihnita disagrees.
This is pretty fundamental, and we need a resolution.
@mihnita Did I understand right that you were going to add here your summary of my presentation from yesterday? Or is that somewhere else?
The summary is the one you posted on meeting notes?
Make sure we add to the spec some security considerations for custom functions:
no access to anything
access to a context, TBD what it contains
access to everything
aside from that if there is something else that summarizes the last meeting ideas(issue/discussion/document)please link it here too.
cc @mihnita
I have submitted #197 as a proposed consensus statement based on Monday's call.
Make sure we add to the spec some security considerations for custom functions:
This is an accurate representation of the general point.
- no access to anything
- access to a context, TBD what it contains
- access to everything
This appears to be a list of options for one possible solution to the security issue that was raised? The solution I proposed was somewhat different, as it removed runtime context access from all formatting functions.
it removed runtime context access from all formatting functions
I don't think it is safe to add that limitation at this point. In that it is too early, and we don't even know (yet) exactly what the formatting functions look like, and we did not define what is in that "context" In a different issue we are still debating if we have more than one kind of functions, where I argue for at least 2 (formatting and select). And I think you are arguing for one kind of function only.
So if we replace the areas that are under-specified or not yet captured in the spec ("formatting functions" and "context") this reads as "The solution I proposed ... removed runtime FOO access from all BARs"
Yes, we might say "well, we have a reasonable understanding of these aspects we also lock this door"
That is what I tried to do with the 3 bullets: list all possible options, make it clear than context needs to be defined, but without making decisions on what we restrict on what until we know better.
@mihnita Should your previous comment perhaps be a review of the actual PR #197?