draft-phillips-langtags-04 /2.4.2 Maintaining private-use tags

[Tex Texin]

I am not sure that bullet 4 is a good recommendation. It says that
implementations that choose not to interpret privateuse or extension subtags
should not modify them.

Private use is a BAD thing where there are no agreements. Perhaps the caution
against them should be more strongly stated.
(Also "choose not to interpret" is perhaps too kind to those who impose private
extensions on the general population. How about "implementations that were not
informed of your little private agreement" ;-) )

Anyway, if my "implementation" makes changes to a document labeled with a
privateuse subtag, I no longer know if the privateuse subtag is still valid. My
changes may have invalidated it. Also, if I changed script or some other aspect
of the content, and I update the script subtag to reflect my changes, I don't
know if the extension still meaningfully applies.

Further, I might also have a need to indicate a privateuse subtag on the
modified content and would like to add it to the tag now.

Once I accept assorted content that has private extensions that I am unaware
of, what do I tell my user community about the subtag values?

What about my UI and the database schema that holds this content? I don't have
any agreements, but I still need to display these values or allow searching to
find (or perhaps ignore) documents with these add-ons? 

I guess I should clarify that I don't expect my user community to be familiar
with or specify language tags. Instead I would compose them from individual
controls for language, script, region, etc. I don't see the value in adding
support for privateuse where it causes confusion in the general design and can
only be explained with "Don't use it".

It might be preferable to allow privateuse subtags only among applications that
agree to their existence, and the rest of us can drop them. It would mean that
general purpose applications would need a way to register privateuse subtags
(even if they didn't do anything with them) to allow them to be maintained in
tags. But that would make it clear how undesirable these things are.

So I lean towards replacing 4. with a statement that says implementations that
do not support privateuse subtags SHOULD remove them from content that is
modified. (It is perhaps ok to maintain the values on content that is processed
but not modified.)

Of course, if the entire tag is private, the tag should be maintained.

I guess I need to see some strong use cases for privateuse subtags that justify
the burden and chaos they impose on the general population.

tex