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

Tex Texin tex at xencraft.com
Sat Jul 3 17:16:05 CEST 2004 

Mark,

My concerns are:

1) We have 2 mechanisms. What is the justification (need) for adding the third?

2) I do believe there is a difference, because the third form is a mix of
standard values and private riders.
The first 2 are self-limiting because they force the user to give up some
standard support. The third is very open ended.

Especially, with the (mis-)use of language identifiers as locale tags, this
mechanism could be very prone to extension.
One could use x-dmy, x-ymd, x-mdy, etc. to indicate date format, x-Tnn where nn
indicates time zone offsets, etc.
currencies- x-usd,x-eur
So my locale is en-Latn-US-x-mdy-x-usd...

We tend to presume private agreement means 2 parties off on their own. But a
large vendor could easily adopt some patterns that create defacto standards. It
seems much less likely to happen with the first 2 options.

3) As for security, I am not worried that for example that my private use tag
will trigger some odd result in someone else's app.
I do have a concern that someone else's software, which I integrate with, might
have some operations that they, or someone knowledgeable about their
application, can do something harmful (which includes returning private
information to them, not just crashing the system). Specifically, I am
objecting to the "SHOULD not remove...".

Unlike character data, I think I should be able to prevent operational commands
from coming into my system, where I have no knowledge or agreement to support
them. They also represent a set of behaviors that I cannot test in my system,
since I don't know the values that are commands.
At least with the reserved Q codes, there is a finite list which I can test
with, even if I don't know their intent.

4) I also indicated that if I can't remove the private use tags, that it
imposes some work to maintain them. 

If I can remove them, then it is minimal work, not a security risk, and is more
likely to be of use only in private agreements.
If the "SHOULD not remove" (in section 2.4.2 on matching) goes away, I don't
object much, although as Harald said, having a third mechanism seems excessive
and makes the spec much more complicated than seems justified.

Why do you and Addison want the feature in?

tex


Mark Davis wrote:
> 
> I see no essential difference between the following in terms of private use
> behavior, where the first 2 are permitted now in RFC 3066, and the third
> would be permitted under draft-04.
> 
> en-QM
> x-en-texsecretswitch
> en-x-texsecretswitch
> 
> I think your mention of security is a red herring here. If you interpret
> private use codes -- ANY of the above -- then you had better have
> established a private agreement for their use. And you had better either
> carefully filter everything that comes from a different source, or have
> harmless behavior in case you get something from the outside the private
> agreement. Thus if Joe does something dumb like interpret *any* of the above
> as instructions to reformat a hard drive, then Joe has a really bad design.
> But Joe could have done that bad design with either of the first 2 with the
> current RFC 3066 also. I don't see that 3066bis makes any essential
> difference in security here.
> 
> That being said, we could certainly beef up the cautions about any private
> use in 3066bis, which already has more cautions than what was in 3066, and
> add a note referencing that in the Security section.
> 
> Μаrk
> ----- Original Message -----
> From: "Tex Texin" <tex at xencraft.com>
> To: "Mark Davis" <mark.davis at jtcsv.com>
> Cc: "Doug Ewell" <dewell at adelphia.net>; <ietf-languages at alvestrand.no>
> Sent: Friday, July 02, 2004 12:07
> Subject: Re: draft-phillips-langtags-04 /2.4.2 Maintaining private-use
> 
> > Thanks Mark, I am happy to be corrected if I misunderstood.
> >
> > However, the private use subtags are what I was refering to:
> > "x" 1*("-" (1*15alphanum))
> >
> > And whereas you can use qaa and QM today, qaa is not likely because using
> a
> > private primary language means giving up any language support you might
> have
> > with integrated software.
> > QM is possible but potentially will conflict with some other assignment of
> > semantics to it by other software.
> >
> > However, I can probably append x-texsecretswitch to existing tags, get the
> > expected language support plus use it to trigger specialized behavior in
> just
> > my programs (including backdoors and potential security risks) and not
> conflict
> > with anyone elses private codes, except where appending them exceeds the
> > maximum length for a tag.
> >
> > I don't see why these subtags are needed or why software should attempt to
> > carry and maintain them.
> > Why not just leave the standard with the existing private use codes as
> good
> > enough?
> >
> > If they are not getting a lot of use today why extend them?
> >
> > tex
> >
> > Mark Davis wrote:
> > >
> > > That is incorrect. The current private use ISO 639 and ISO 3166 codes
> are
> > > valid codes in their respective standards. So I can in the current RFC
> 3066
> > > produce codes like:
> > >
> > > en-QM (English with a private use region)
> > > qaa-US (Private use language with US region)
> > >
> > > I'm sorry that I haven't had a chance to respond to a number of the
> comments
> > > so far. Addison and I discussed them before he flew off to Russia, so I
> will
> > > try to answer them for the both of us in his absence, after the holiday
> > > weekend. However, I find that quite a few of them are on the order of
> the
> > > comment below; not recognizing that the current draft in many cases
> simply
> > > documents and makes more rigorous a pre-existing capability (from the
> > > current 3066).
> > >
> > > Îoаrk
> > > ----- Original Message -----
> > > From: "Tex Texin" <tex at xencraft.com>
> > > To: "Doug Ewell" <dewell at adelphia.net>
> > > Cc: <ietf-languages at alvestrand.no>
> > > Sent: Friday, July 02, 2004 11:01
> > > Subject: Re: draft-phillips-langtags-04 /2.4.2 Maintaining private-use
> > >
> > > > Doug,
> > > >
> > > > In the current situation only the entire tag is private. This limits
> its
> > > > usefulness since if you use a completely proprietary tag no other
> software
> > > will
> > > > do anything useful with it.
> > > >
> > > > The proposal though is to allow amending of supported tags with
> private
> > > > add-ons. This creates an expectation that the tag will be generally
> > > supported
> > > > and carry around the add-on with it. I suspect it will be used not
> only by
> > > > private agreement for interchange with others, but as note-to-self in
> some
> > > > applications. (e.g. Turn on this feature or that.)
> > > >
> > > > So it may be more generally used and therefore be a more significant
> > > issue. And
> > > > yet I am unclear as to the demand or need for this.
> > > >
> > > > tex
> > > >
> > > >
> > > > Doug Ewell wrote:
> > > > >
> > > > > Tex Texin <tex at xencraft dot com> wrote:
> > > > >
> > > > > > Private use is a BAD thing where there are no agreements. Perhaps
> the
> > > > > > caution against them should be more strongly stated.
> > > > >
> > > > > I repeat what I said earlier this week:  Is it genuinely a problem,
> in
> > > > > the real world, that people are using private-use codes or tags
> where
> > > > > there is no agreement, leaving users clueless as to what they mean?
> > > > >
> > > > > Can anyone cite instances where this was an actual problem?
> > > > >
> > > > > Failing that, is the strength of the caution really a significant
> issue?
> > > > >
> > > > > -Doug Ewell
> > > > >  Fullerton, California
> > > > >  http://users.adelphia.net/~dewell/
> > > > >
> > > > > _______________________________________________
> > > > > Ietf-languages mailing list
> > > > > Ietf-languages at alvestrand.no
> > > > > http://www.alvestrand.no/mailman/listinfo/ietf-languages
> > > >
> > > > --
> > > > -------------------------------------------------------------
> > > > Tex Texin   cell: +1 781 789 1898   mailto:Tex at XenCraft.com
> > > > Xen Master                          http://www.i18nGuy.com
> > > >
> > > > XenCraft             http://www.XenCraft.com
> > > > Making e-Business Work Around the World
> > > > -------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > Ietf-languages mailing list
> > > > Ietf-languages at alvestrand.no
> > > > http://www.alvestrand.no/mailman/listinfo/ietf-languages
> > > >
> >
> > --
> > -------------------------------------------------------------
> > Tex Texin   cell: +1 781 789 1898   mailto:Tex at XenCraft.com
> > Xen Master                          http://www.i18nGuy.com
> >
> > XenCraft             http://www.XenCraft.com
> > Making e-Business Work Around the World
> > -------------------------------------------------------------
> >
> >

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex at XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

More information about the Ietf-languages mailing list