comments on the draft - extensions

[Peter Constable]

My only remaining comments have to do with the Extensions mechanism
(section 3.3). 

I'm struck by what seems to me to be unprecedented: In defining a
protocol, mechanisms are incorporated in order to support some
unspecified future higher-level protocols. In part, it strikes me as
being sort of like UTC designating a range of codepoints (say)
U+EF000..U+EFFFF for possible future "courtyard" characters with no hint
of what these things might ever be -- and there's no question that UTC
would not accept a proposal to do something like that without knowing
that there was a specific plan and knowing what that plan was. So, it
seems a bit unusual that we're being asked to adopt something for
"applications that may be created... in the future."

But this is even more unusual because, in the Unicode analogy, the
mechanism would have to be defined by UTC as they own the codespace,
whereas here a higher level protocol could extend tags defined by RFC
3066bis without interfering with the latter's codespace, yet instead the
mechanism is being put squarely in the codespace defined by RFC 3066bis.
The only reason I can conceive for putting mechanisms here rather then,
say, allowing a subsequent RFC defining a higher-level protocol that
uses tags of the form (say)

language-tag "_" extensions

is to ensure that these future tags can be transported in any protocol
that references RFC 3066bis. So, if someone managed to establish a
protocol with some registered singleton subtag, say, "c" for a set of
"courtyard codes" that might be used in DVB applications to perform a
variety of text transformations (e.g. this text is English and should be
displayed with a blue outline and flashing green/black fill), then
*every* protocol that uses RFC 3066bis will need to permit these. 

Sure, not every protocol has to interpret them, and it would always be
acceptable to ignore them. But it's an additional complexity, and an
opportunity for people to do things wrong. Especially if one of the
extensions that gets established has to do with something that
implementers already find confusing, such as locales. It wouldn't be
hard to imagine, for instance, people tagging content with something
like "en-US-d-yyyymmdd" in places where it really isn't appropriate.

Maybe there is a particular plan for the future that the authors have in
mind, and perhaps a good plan. But I think it's only reasonable that
there be at least some discussion of what kinds of future extensions
might be considered appropriate, whether there is any concern of
inappropriate extensions getting created ("courtyard" codes?), and
whether there's any concern over every RFC 3066bis consumer needing to
accept whatever extensions might come along.



Peter Constable