Re: [Ltru] Mail regarding draft-ietf-ltru-4646bis and draft-ietf-ltru-matching

[Florian Rivoal <[e-mail]>]

> On Aug 28, 2019, at 2:47, Doug Ewell <[e-mail]> wrote:
> 
> On July 27, Florian Rivoal wrote:
> 
>> However, RFC5646 Section 4.5, which defines canonicalization, only
>> does so for language tags, not for language ranges. Presumably, the
>> process is largely the same, with wildcards in the language subtag
>> being preserved, and I suppose wildcards in other subtags would likely
>> be dropped. But as it stands, that seems undefined.
> 
> I think you are on the right track by assuming that ranges are
> canonicalized just like tags, with asterisks left alone.

Thanks for confirming.

> It's not very likely that most LTRU participants will be eager to start
> up a new IETF project to update 5646 for something like this. Best to go
> with your assumption.
> 
>> Also, while giving recommendations about canonicalization for the
>> purpose of filtering, it would seem useful to mention (and possibly to
>> recommend) canonicalizing to the "extlang form". The definition of the
>> extlang form itself (in  RFC5646 Section 4.5) mentions that it is
>> useful for matching and selecting, but that information isn't relayed
>> anywhere RFC4647.
> 
> At the time these documents were written, there was a strong sentiment
> around de-emphasizing extlangs in general. It's good to know that
> there's a real-world use case for using them here. Again, it's unlikely
> that people will want to rev 4647 for this.

The use case is CSS selectors, when writing rules for typography/styling in a document. On the one hand, the document gets marked up which part of it are in which language. On the other side, the style sheet describes which part of the document must be styled which way, and can make that styling dependent on the language.

The need for normalization comes from the fact that stylesheet authoring and document authoring are not coordinated in the general case, so a stylesheet author cannot know, generally speaking, if a document will be marked up with, for example, zh-yue or yue. The stylesheet author is then faced with two options, both unattractive for different reasons:
* use the deprecated tag: it's more likely to be found in existing documents due to being older. The first downside is that it doesn't always work. The second one is that this slows down adoption of the newer preferred tag, as document authors wanting to be compatible with existing stylesheets will keep on using the deprecated one as well for compatibility, and we get into a vicious cycle of everybody continuing to use the deprecated variant.

* Use both the deprecated and the preferred tag in the stylesheet's selector. This works, but it means that stylesheet authors need to be aware of, and manually replicate the information in https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry. Asking people to manually do what software could isn't great, as they tend not to, or to do it with bugs, or to not update when the registry updates, etc.

So it seems preferable, given that this correspondence is maintained in a neatly usable format, to have CSS renderers deal with the correspondence between deprecated and preferred tags by way of canonicalizing to the extlang form and doing the selector matching on that.

In the long run, both document authors and stylesheet authors should use the preferred tag without the extlang prefix, and the canonicalization to extang form will be invisible to them. But even if some don't, everything works.

—Florian