Meeting minutes
Agenda Review
Action Items
<addison> https://
<addison> #184
<gb> Action 184 reply to wcag issue with comment about doing a higher level of interaction and pre-review (on aphillips) due 2025-09-04
<addison> #135
<gb> Action 135 follow up on XR issue 1393 about locale in session (on aphillips) due 2024-10-17
<addison> #127
<gb> Action 127 make a list of shared topics of interest between TG2 and W3C-I18N (on aphillips) due 2024-09-30
<addison> #33
<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)
<addison> #7
<gb> Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github) due 18 Jul 2023
<addison> #4
<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on aphillips) due 27 Jul 2023
Info Share
<addison> xfq: Unicode 17
<addison> ... it was published
r12a: you can enjoy yourself while reading it now
… it's more beautiful
Review RADAR Review
<addison> https://
<r12a> Announcement: https://
<r12a> Latest core spec online: https://
Bert: I can review css-color-adjust-1
Pending Issue Review
<addison> #2024
<gb> Issue 2024 not found
<addison> i18n-activity#2024
<gb> Issue 2024 Invalid BCP 47 tags? (by xfq) [pending] [t:lang_values] [wg:timed-text] [s:dapt]
[xfq introduces the pending issue]
addison: what we generally do is recommend that specs only require well-formedness unless they have a good reason to do validation of language tags
… because validation means having a copy of the registry
<addison> https://
addison: when I looked through that section especially later on they have an example
addison: I'm not sure what they're trying to show non-linguistic content
… there's a tag for non-linguistic content
… which they could use
… having it empty is just as good
r12a: and why do they have a language tag for xml:lang but not for daptm:langSrc?
xfq: when it's empty?
r12a: yeah
addison: at the very bottom of example 24, they talk about if the Arabic text was translated into Japanese
… the xml:lang for the text would be ja but the source language would still be Arabic
xfq: @@
addison: they don't talk about 'zxx' as a language tag
… you can actually have a language tag that says this is non-linguistic
<addison> > The value MUST be an empty string or a language identifier as defined by [BCP47].
addison: they should make clear what they're trying to do
xfq: so two comments, one about well-formedness, the other about the text below, to make it clearer
addison: sounds good to me
<addison> i18n-activity#2025
<gb> Issue 2025 DID parameters require ASCII-only (by aphillips) [pending] [needs-resolution] [t:char_ranges] [s:did-resolution]
addison: I have several on DID resolution
… DID is Decentralized Identifier
… DID defines several parameters
… several of those parameters require that the value be an ASCII string
… one of them permits percent encoding, I have a separate comment about that
… but the others, it's not clear why they are restricted to ASCII
… in URLs, it's inconvenient to have non-ASCII strings
… in particular, they have a thing called service
<addison> > https://
addison: seems like you might want to name that thing something other than ASCII, at least some of the time
… this is a URN-ish syntax
addison: think of it as UUID, but different
… developers can use this to refer to items or documents or something in an unambiguous way
r12a: ok, but they can refer to a document or context that has a URL that is not ASCII
addison: I think they hide the original URL by assigning names
… they hide it behind this opaque ASCII string
… and you might want the string to be highly portable
… like letters, digits, and dashes
… but then there's a document which is a JSON document which contains the actual references
r12a: but it also has context properties, which are URLs
… can they be multilingual?
addison: those are IRIs
r12a: ok
addison: they don't show that
<addison> i18n-activity#2025
<gb> Issue 2025 DID parameters require ASCII-only (by aphillips) [pending] [needs-resolution] [t:char_ranges] [s:did-resolution]
[[[
service Identifies a service from the DID document by service ID. If present, the associated value MUST be an ASCII string.
]]]
<addison> i18n-activity#2026
<gb> Issue 2026 `relativeRef` should prefer UTF-8 for percent encoding (by aphillips) [pending] [needs-resolution] [t:resid_misc] [s:did-resolution]
[[[
The value of the id property MUST be a URI conforming to [RFC3986].
]]]
addison: if you have some octets that are non-ASCII then you need to percent escape them
<addison> /
addison: but they don't say what character encoding is associated with the percent escaping
addison: at some point these things need to go into HTTP headers etc.
… they want to make these as transportable as possible
… they have parameters whose values themselves can be non-ASCII
… we've already learned the hard way
… that if you don't define the encoding, you'll have to do encoding guessing later
… query parameters on HTTP GET, what's the encoding of that?
… it's the encoding of the page was sending it
<atsushi> https://
<addison> i18n-activity#2029
<gb> Issue 2029 Use character reference notation and Unicode names for references to specific characters (by aphillips) [pending] [needs-resolution] [t:char_ref] [s:did-resolution]
addison: they mention some characters by name in their spec, and we want to recommend our character notation
… any objection to that?
r12a: these are ASCII characters
… do we need to put the name in?
addison: it's our policy to say when you name a character, you should do this
<addison> i18n-activity#2030
<gb> Issue 2030 Define timestamp format carefully (by aphillips) [pending] [needs-resolution] [t:loc_time] [s:did-resolution]
r12a: it would certainly be more precise
… I guess that's what specs are about
r12a: you should put a link to specdev
https://
addison: their metadata has several values for created or updated timestamps
… they semi-define it in passing
… "MUST be a string formatted as an XML Datetime normalized to UTC 00:00:00 and without sub-second decimal precision"
addison: and then they give an example
… my first comment is you should define the thing
… clearly
… and then reference that definition
… "normalized to UTC" isn't defined anywhere
<addison> i18n-activity#2031
<gb> Issue 2031 RFC9457 again (by aphillips) [pending] [tracker] [s:did-resolution] [t:errors]
addison: DID Resolution on errors
… includes a reference to RFC 9457
… a year and a half ago, we talked about this RFC
… it doesn't provide language negotiation or multilingual error packaging and so on
… maybe this is just a reminder that this problem is out there in the wild
xfq: when we talked about this RFC, did we talk about it in the DID context, or in another context?
addison: no, we talked about it in another context
xfq: ok
addison: I didn't find that comment, need to search
… you can see in their text
… "The title value SHOULD provide a short but specific human-readable string for the error."
… but there's no mention of how the locale negotiation takes place
Bert: what can the DID group do about it?
addison: they could define something to deal with the gaps that 9457 doesn't supply
… maybe this is something we should think about but not file as an issue against DID
… I'll go do the research and add it to the agenda next week
ICANN UA meeting on Tuesday
<r12a> Are there any specific standards ICANN org should contribute toward for promoting UA adoption across applications and systems? Are there any emerging topics to consider for standards work for UA which ICANN org should consider? Which organizations should it collaborate with for the work? How should ICANN org prioritize its contribution to standards work related to UA?
r12a: next Tuesday, we begin a discussion on standards related to Universal Acceptance
… see the questions ^
… I would be very grateful if you guys could send me things that I should say for each of these questions
… would be even nicer if some of you are available to have a Zoom call with me to go through it
addison: do you want to put a Zoom call on the calendar somewhere?
r12a: I'd be happy to do that
… in the meantime, if any of you would like to send me an email
video about lang attribute
r12a: and provide what you think might be useful answers
https://
<gb> Issue 774 Add video about the lang attribute (by xfq)
<Zakim> Bert, you wanted to ask if the video can be put on the TPAC videos page (which is meant for groups to talk about their work ahead of TPAC): https://
[xfq introduces the video]
xfq: I recently started making some videos. Videos can be another form of "articles". Some people like to learn by watching videos, and some people like to learn through articles. I hope that both types of people can learn from our educational material.
addison: I think we can experiment with it
… if you had 50 of these and they were all embedded in a page, what you just have is a long list of stuff
… at which point, you've replicated YouTube's playlist concept or something
… I think this is great
<xfq> In addition, more people find our articles directly through search engines, and not many people browse the article list directly.