RE: [Ltru] Re: Remove extlang from ABNF?

> From: Doug Ewell [mailto:dewell@roadrunner.com]

> >> That's my whole point - the danger that specs writers might look at
> >> the dropped extlang and say "they are dropping features between
> >> versions of  BCP 47, so we better refer to an RFC *only* and even
> >> leave 'or its successor' out".
> >
> > But this is a key: we are *not* dropping any features. We are
> dropping
> > the possibility of a future feature. The change to the ABNF (whether
> > by removing the extlang subtag entirely or by renaming and/or
> > comments) is to clean it up so that implementers do not implement for
> > non-and-never-to-be-features.
>
> I think what Felix meant was not that we are dropping features, but
> that
> it may appear to the outside observer that we are dropping features.

I understood that. But I think it's significant that we are *not* removing any features, and it seems to me that could be explained easily enough.

The only real stability concern is that some existing parsers would recognize certain hypothetical tags they might encounter as being well formed when in fact they are not well formed. What possible malicious effect could this have? Is this a tag in a query statement? It very likely won't match any content. Is this a tag attributed to content? There likely won't be any requests for it. Only in some closed system in which somebody decided to use proprietary extlang subtags are both going to exist by design. If the parser is encountering a tag somehow constructed such that it has a not-by-design extlang, it won't be catching an condition that could be considered an error, but the error will still be reflected in a failure to match anything, and the essential fix must be in the process *constructing* that tag rather than in the parser.

Peter