Skip to main content

Appeal over a key change in a poor RFC 3066 bis example (JFC Morfin; 2005-10-19) - 2005-10-19
Appeal - 2005-10-19

Subject: Appeal over a key change in a poor RFC 3066 bis example.
Date: Wed, 19 Oct 2005 17:12:11 +0200
From: r&d afrac <>
CC: Scott Hollenbeck <>
References: <> <>

Appeal to the IESG

Upon the advise of the WG-ltru co-Chair, I formed the following
appeal to the WG-ltru AD less than 30 minutes ago. This appeal
concerns the core issue of the RFC 3066 bis doctrine (the private-use
space) through the correction of a supposed "typo". IMHO, the
understanding of this tricky case,calls for a real analysis of what
is implied, and of my positions.

I received the following response.

At 16:27 19/10/2005, Scott Hollenbeck wrote:

Appeal denied. In my opinion this is an editorial change that does not
alter the specification in any way. You may appeal my decision to the IESG
if you disagree with my assessment.

So, I must appeal to the IESG.

The reason why is that the decision belongs to a doctrine I - and
many throughout the world - do and will oppose with the highest
determination. I do not want to enter in the dispute to know if this
doctrine is right or not. It is just that these many need to know if
the IESG (and possibly the IAB) adhere to that doctrine they consider
as lethal to them, their culture and their country.

I note that my personal proposition is a simple way, conforming with
existing RFCs and the spirit of the RFC 3066 bis, to technically
support both doctines (and the involved interests). This particular
case is precisely about:

  • a clumsy example where RFC 3066 bis documents how this could start
    being done.
  • that one now want to change to make it "consistent" over another issue.

The above opinion brought by Scott Hollenbeck does not call for any
comments since it is not documented.

Liminary information

However your were not copied Scott Hollenbeck documented this to your
attention, but did not add any comment. Here is his text:

For the benefit of the IESG, this is the text in question as it appears in
the ballot write-up:

Note to the RFC Editor:

Please replace zh-Hant-CN-variant1-a-extend1-x-wadegile-private1
by zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 on
page 43 of draft-ietf-ltru-registry-14 in chapter 4.3.2 for
consistency with the immediately following zh-Latn truncation
example on the same page. This typo was found after the IESG
evaluation and confirmed by the authors.



Original appeal forwarded to the IESG

Appeal to AD

A change in the text of the RFC 3066 bis has been proposed. You have
asked if a consensus supported it.

  1. I oppose this change
  2. I note the reasons of that opposition are mis-represented by the co-Chair
  3. I note that the reasons given to support that change substantially
    modify the nature of a key part of the document
  4. I note that the number of persons having supported the change seem
    to do it for contradictory reasons and that their number make my
    opposition significant.

At 05:03 19/10/2005, Randy Presuhn wrote:

As co-chair:
We do not need WG consensus to correct an obvious (once
spotted!) typo in an example. If you object to the decision to
correct this typo, please feel free to appeal to the AD, etc.

I do not object any "decision to correct" a "typo".
I object that the proposed correction concerns a typo.

Consequently I appeal to the "AD" as suggested by the WG-ltru co-Chair.
I regret the "desinvolture" of the WG-ltru co-Chair regarding the
IETF appeal rights qualified as "appeal AD, etc.".

Reasons of the appeal

I am concerned by the ability of the document to support the expected
billions of different user needs. The users I refer to are individual
users, users communities, corporations, ISPs, nations, SSDOs such as
MPA, MPEG, etc. and TLD Managers. The support of these needs is not
the priority of the WG-ltru members consensus. I however
painstakingly obtained that two things:

  1. a clear far less "leaking" ABNF for the support of the WG-ltru proposition.
  2. the respect of the RFC 3066 private-use area.

This respect was documented many times against my demand for longer
fields and the support of more characters. This was done in telling
me that whatever scheme I could imagine, it was supported through
the "x-" private-use area, through one or more "-" separated block
of 1 to 8 alphanums.

I have therefore every reason to believe that the "typo" results from
the preoccupation to demonstrate - through that unique example - that
my demands could be satisfied through the private-use space, and to
reduce my opposition.

  1. removing it would change the way the reader would understand the document.
  2. this change should have been subject to the Last Call.
  3. the objections to my objection object to the very nature of the
    "x-" private-use space.
  4. observers could consider that the "correction" was asked once the
    "typo" plaid its role.

I can only repeat what I said:

  1. This example may not be the best. But it is the only one in the
    document showing the orthoginality between the registered subtags and
    the privateuse area, and the possibility to have a private scheme
    with a default.

There are two different kind of contradictory opposition to my opposition for:
- orthogonality/scalability reasons
- versatility reasons

1. orthogonality

In this example: private1 makes x-wadegile is related

to Hant, while the defqult (without private1) is related to Latn.

This position is related to the structure of the langtag and to the
independence of the private-use content from the standard. This
should be the very nature of the private use:

  • the standard has no constraint on the private-use space, except its ABNF
  • the user of the private-use space is the master of his langtag.

This is general, transparent, scalable. This is opposed by:

At 05:03 19/10/2005, Randy Presuhn wrote:

As technical contributor:
That is not the purpose of the example. Anyone familiar with romanization
schemes for Chinese will find your interpretation highly implausible.

This presupposes that "wadegile" has a special meaning for the
standardiser (here the WG-ltru co-Chair as a contributor). This means that:

  1. he thinks to "wade-giles" the format has been changed
    - in removing the "-", "x-wadegile" and "x-wade-giles" having
    not the same meaning
    - truncating legitimate words to fit the arbitrary limit of 8 alphanum
    - presupposing in the document an external relation not
    documented in the document.

  2. this "wade-giles" understanding for "wadegile" conflict with other
    I explained that for me it was related to the gile of the
    Senator Wade (Ohio).

  3. the hurting comment about my right being transformed in an highly
    implausible interpretation, shows that my objector (and first
    supporter for the "correction") totally misunderstand the nature of
    the "x-"private-use space.

I note that this error is common enough since I foresaw it:

This example is correct. Even if it may not be ideal and considered
as "politcially incorrect", in reference to Harald's mail of apology
on the privateuse area.

2. structured private scheme

The importance of the example is not only to show the independence of
the private-use space from the standard. It is also to demonstrate -
at least in part - its possibility to support "any scheme I can
imagine". This example shows two more extended possibilities:

  • default
  • truncation

This is opposed by :

At 06:30 19/10/2005, Doug Ewell wrote:

It's not even that. The error in question has nothing to do with using
"x-wadegile" together with "zh-Hans". It has to do with the fact that
the lines which follow use "zh-Latn" instead, which breaks the
illustration of how truncation works.

Apart from disagreeing with the preceding position, for reasons I
share. This opposition actually supports my position.

In the first use, "x-wadegile-private1", uses a "private1" subtag: we
will understand as a scheme-subtag sequence. In the second use,
truncation removes the subtag: only the private scheme is indicated
and default conditions apply, with in this case a different script.

This opposition is therefore correct. But the example does
illustrates truncation only. It illustrates:

  • truncation (last lines)
  • default in private use (first line)
  • truncation in case of a default in private use (two first lines).

The illustration of the default case may rise additional questions in
the reader's mind. These questions are the questions I rise, as
user's QA only interested person, on the private-use issue. The
WG-ltru consensus and WG-ltru co-Chair may not wish it from the following:

At 07:58 28/09/2005, Harald Tveit Alvestrand wrote:

Subject: [Ltru] Oops..... apologies for platform provisioning...
it seems that my remark on private-use tags has been seized upon by
Jefsey and used as an argument against publishing the documents again.

That was not my intention. My opinions on private-use tags in
general are just my opinions, and was not intended to ask for any
change in the documents at all; I know it's not a consensus position.

Let's respect the WG chair and move further discussion (if needed)
off this list.

3. Final comment

At 05:03 19/10/2005, Randy Presuhn wrote:

As co-chair: at this stage of the process, adding new material would be

I can only agree with this co-Chair's statement. The proposed
"correction" adds new substantial material after the LC.
It would be inappropriate.

Sincerely yours.
J-F C. Morfin