[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ltru] Re: singleton DIGIT



r&d afrac wrote:

> RFC 3066 permitted digits in subtags.

We're talking about singletons, RfC 3066 says:

 [primary subtag]
| The value "i" is reserved for IANA-defined registrations
| The value "x" is reserved for private use.  Subtags of "x"
| shall not be registered by the IANA.
| Other values shall not be assigned except by revision of
| this standard.

Either "i-" or "x-" or more letters, no single DIGIT.

 [secondary subtag]
| Tags with 1-letter second subtags may not be assigned
| except after revision of this standard.

No single letter or DIGIT.  The first position where a single
letter or DIGIT was allowed was the third subtag.  I recall it
now, we discused it here, that's why the single DIGIT was
added for future extension subtags.

And because 3066bis is a revision of "this standard" - wow, a
sure kill for any 3066 last call - we're free to allow it also
in the second position.

But not in the first, exactly as the 3066bis ABNF does, it's
correct.  Addison could s/letter/letter or digit/ exactly
where Doug found it in the prose.

> What Doug says is "I cannot support it in the document I
> write since I did not write that I would".

After five months you're supposed to know who writes which
document.  Addison or Mark fixed the missing DIGIT, not Doug.

> This kind of position will obviously not hold for ever in
> front of IESG, IAB, GAC, WTO

It might also cause serious problems with the KERC (Klingon
Equal Rights Commission), they'll insist on a singleton € ;-)

> This is why I am spending so much time explaining the
> obvious again and again. To give "lawyers" quotes enough
> to discuss the bad or the good faith of the authors.

There's nothing wrong with the authors, aim higher.

> ABNF is not the point.

IBTD.  Sometimes I can see the ideas behind the ABNF, where
the prose is only MUSTardized irrelevant whishful thinking
(that remark wasn't about the drafts here).

> The point is political and commercial.

It's technically sound and causes no harm, unlike this beast:
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1573&filename=draft-lyon-senderid-core

> Study http://www.unicode.org/history/boardmembers.html and
> http://www.unicode.org/consortium/directors.html

Thanks, I didn't know these links.  I sometiems check corporate
members for DoubleClick or SpamCast (guess why).  Unicode is a
white hat, see http://www.unicode.org/consortium/memblist.html

> So, you understand why this Jefsey is a very bad/poor stupid
> troll, making "industry" to waste huge amounts of money with
> his "delaying practices".

I'm not worried about your activities, but I do get angry if
you insult or even harrass others as you tried it with John.

Each WG needs its resident kook, it helps to focus - without
you we could be tempted to get arried away inventing wild and
wonderful things that nobody wants or needs.

Disclaimer:  It was less useful when you wasted Martin's or
Randy's time, they're not free to click NEXT whenever they feel
like it.  Your articles tend to be too long  (nothing personal,
I have the same problem, but it's bad, after 50 lines readers
give up and click NEXT).

> The whole thing is format exclusiveness, so _every_ book
> and page in the world can fit in a unique industry controlled
> format.

While we're "not" discussing personal problems, if somebody is
apparently more paranoid than I am I think it's a bit too much.

> The supposed retrocompatibility obligation with a never used
> format is only a bluff.

IBTD.  Ira, Ned, and I insisted on the "Suppress-Script" for
maximal backwards compatibility, _not_ Addison or Mark, they
hated it.  And JFTR, nobody paid me for my opinions here.  It
is just what I think how this stuff could work in all contexts
I'm somewhat familiar with.
                              Bye, Frank



_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.