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 To: iesg@iesg.org CC: Scott Hollenbeck References: <6.2.3.4.2.20051019130844.03af4370@mail.afrac.org> 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. > >OLD: >zh-Hant-CN-variant1-a-extend1-x-wadegile-private1 > >NEW: >zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 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: > > 2. 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 understandings. 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 >inappropriate. 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 AFRAC, VP R&D