<div dir="ltr"><div>I went through the anchors you added, and have some responses.</div><div><br></div><div>First, as far as your final statement:</div><div><br></div><div>> (1) if we decide to start moving "normative" material out of</div>
<div>> Rationale and into either Protocol or a separate document, we</div><div>> are first going to have to agree about what material falls into</div><div>> the "normative" category. I believe that the analysis above</div>
<div>> suggests quite strongly that it is not a simple decision with an</div><div>> obvious answer.</div><div><br></div><div>If it is not clear what is and isn't normative, we have a huge problem on our hands! If we can't decide, there is no way on earth ordinary users will be able to know what is and is not required for implementation, representing a severe interoperability problem.</div>
<div><br></div><div>There is a general issue in the text in that sections that are informative mustn't contain MUST, SHOULD, etc -- that's normative language.</div><div><br></div><div>=============</div><div><br></div>
<div>[[anchor8: John Klensin believes that the definitions of "IDNA2003"</div><div> and "IDNA2008" in this subsection are normative and required to</div><div> understand discussions in Protocol, Bidi, and Tables.]]</div>
<div>Agreed, and should be moved to protocol or Terminology document. (I'll abbreviate this by "to protocol" below).</div><div><br></div><div> [[anchor10: Mark Davis proposes to move this section out as normative</div>
<div> text.]]</div><div> [[anchor11: John Klensin believes this is normative and required to</div><div> understand Protocol.]]</div><div><br></div><div> [[anchor15: Mark Davis proposes to move this section out as normative</div>
<div> text.]]</div><div> [[anchor16: John Klensin believes this is normative and required to</div><div> understand Protocol and Tables.]]</div><div>I don't disagree; it should be normative and in Protocol.</div>
<div><br></div><div> [[anchor22: John Klensin believes it is possible that this may be</div><div> required to understand the very careful way in which the term...</div><div> [[anchor24: John Klensin believes that, as with the subsection</div>
<div> immediately above, this section narrows and provides a slightly more...</div><div>After looking it over, I agree with you on these two.</div><div><br></div><div> [[anchor26: This paragraph is somewhat redundant with material</div>
<div> above.It will be dropped in -03 if there are not strong arguments for</div><div> keeping it here.]]</div><div>Agree to drop.</div><div><br></div><div> [[anchor28: Mark Davis proposes to move this section out as normative</div>
<div> text.]]</div><div> [[anchor29: John Klensin believes this is a roadmap and that it is</div><div> not normative in the sense that the IETF ordinarily uses the term.</div><div> It might, however, be considered part of the definition of IDNA2008</div>
<div> (see above).]]</div><div>The last sentence is what I think, is that this is part of the definition of IDNA2008, and should be incorporated there.</div><div><br></div><div> [[anchor31: Mark Davis proposes to move this section out as normative</div>
<div> text.]]</div><div> [[anchor32: John Klensin believes this is definitely not normative.</div><div> It is a description of the IDNA2008 model, but the actual normative</div><div> definitions of "PROTOCOL-VALID", "DISALLOWED", etc. are the rule and</div>
<div> category definitions in Tables.]</div><div><br></div><div> [[anchor33: Mark Davis proposes to move this section out as normative</div><div> text.]]</div><div> [[anchor34: John Klensin believes this is not normative. See comment</div>
<div> at the beginning of Section 5, above.]]</div><div>After looking this over, I agree with you.</div><div><br></div><div>Note that if we see a statment like "... are never removed from ..." or "These characters must not appear in IDNs without.." in informative material, then there must be some place within the *normative* material that has corresponding MUSTs.</div>
<div><br></div><div>[[anchor38: Note in Draft: the permanence of DISALLOWED was still</div><div>under discussion in the WG when this draft was posted. The text</div><div>above reflects the editor's opinion about the emerging consensus but</div>
<div>is subject to change as the discussion continues.]]</div><div><br></div><div>I see no consensus yet; and the statement can't be made anyway without adding a qualifier, eg "unless this document is obsoleted."</div>
<div><br></div><div>[[anchor39: Mark Davis proposes to move this section out as normative</div><div>text.]]</div><div>[[anchor40: John Klensin believes this cannot be normative, since it</div><div>does not contain any definitions or rules: it is simply explanatory</div>
<div>of the role of registry policy activities. There is a requirement in</div><div>Protocol to have such policies, but it stands alone, without this</div><div>subsection.]]</div><div><br></div><div>I disagree. If you want to keep normative language in the section eg "...registries SHOULD develop...", then the section is normative.</div>
<div><br></div><div>[[anchor43: John Klensin asks whether the material in Bidi that</div><div>depends on a clear distinction between Network Order and Display</div><div>order is sufficiently described to be self-sufficient. If it is not,</div>
<div>then either more comprehensive definitions must be added there or at</div><div>least part of this subsection is normative for Bidi.]]</div><div><br></div><div>I don't think we actually need to move it to Bidi, so this could remain non-normative. However, statements like "correct treament ... requires ..." certainly look like they are intended to be normative here.</div>
<div><br></div><div>[[anchor45: Above text is a substitute for an earlier (pre -01)</div><div>version and is hoped to be more clear. Comments and improvements</div><div>welcome.]]</div><div><br></div><div>Commented on in the tranche document. It still overstates the difficulty. If you really think its a problem, then you should give at least one concreate case that shows why.</div>
<div><br></div><div>[[anchor46: Placeholder: there have been</div><div> suggestions that this text be removed entirely. Comments (or</div><div> improved text) welcome.]]</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Commented on in the tranche document.This section should be replaced by a normative statement, in the protocol document that "Localized proprocessing SHOULD NOT be done, because it leads to interoperability problems."</div>
<div><br></div><div> [[anchor48: Mark Davis proposes to move this section out as normative</div><div> text.]]</div><div> [[anchor49: John Klensin claims it is not normative and must not be</div><div> normative lest it be taken as an alternate definition for IDNA2008.]]</div>
<div>I agree that it is not normative. But I think the section still belongs in protocol, because what it is describing is the difference between the IDNA2003 and IDNA2008 protocols.</div><div><br></div><div>[[anchor53: John Klensin believes that this subsection is normative.</div>
<div>It is not merely explanatory because it contains RFC 2119 conformity</div><div>statements and provisions that are not present in Protocol. In spite</div><div>of not being algorithmic, perhaps it should be moved into Protocol.</div>
<div>However, it is an explanation that is important to the non-</div><div>implementer audience.]]</div><div>I agree, and it should be moved to protocol.</div><div><br></div><div>[[anchor54: The above paragraph remains controversial as to</div>
<div>whether it is valid. The WG will need to make a decision if this</div><div>section is not dropped entirely.]]</div><div>It needs to be completely dropped, since it is simply specious. If the criterion were as stated, then we'd remove all the following, since they can all have the same pronunciation:</div>
<div>[㐹 㑊 㑜 㑥 㓷 㔎 㔕 㔴 㖂 㘁 㘊 㙠 㙪 㙯 㚤 㛕 㛳 㜋 㜒 㝣 㞾 㡫 㡼 㢞 㣂 㣇 㣻 㥷 㦉 㦤 㱅 㱲 㲲 㲼 㳑 㴁 㴒 㴔 㵝 㵩 㵫 㶠 㸣 㹓 㹭 㽈 䁆 䂽 䃞 䄁 䄩 䄿 䆿 䇩 䇼 䉨 䋚 䋵 䌻 䎈 䏌 䐙 䑄 䑛 䓃 䓈 䓹 䔬 䕍 䖁 䖊 䖌 䗑 䗟 䗷 䘝 䘸 䚷 䛖 䝘 䝯 䢃 䣧 䣱 䦴 䬥 䭂 䭇 䭞 䭿 䯆 䰯 䱈 䱒 䳬 䴬 䵝 乂 义 亄 亦 亿 仡 伇 伿 佚 佾 俋 億 兿 刈 劓 劮 勚 勩 医 呓 呭 呹 唈 嗌 囈 圛 垼 埶 埸 墿 壹 奕 嫕 嬑 嬟 寱 射 屹 峄 嶧 帟 帠 幆 廙 异 弈 弋 役 忆 忔 怈 怿 悒 悥 意 憶 懌 懿 抑 抴 挹 捙 掖 撎 敡 斁 施 易 昱 昳 晹 曀 曎 曳 杙 枍 枻 栧 棭 榏 槷 檍 欭 歝 殔 殪 殹 毅 汉 泄 泆 泽 洂 洫 浂 浥 浳 液 渫 湙 溢 潩 澤 澺 瀷 炈 焱 焲 熠 熤 熼 燡 燱 獈 玴 異 疙 疫 痬 瘗 瘞 瘱 癔 益 睪 瞖 秇 移 穓 竩 紲 絏 緆 縊 繶 繹 绁 绎 缢 羛 義 羿 翊 翌 翳 翼 肄 肊 腋 膉 臆 艗 艺 艾 芅 芸 苅 蓺 薏 藙 藝 蘙 虉 蛡 蜴 螠 衣 衪 袂 袘 袣 裔 裛 褹 襼 訲 訳 詍 詣 誒 誼 謚 譯 議 讛 议 译 诣 谊 豙 豛 豷 貤 跇 軼 轶 逸 邑 醳 醷 释 釋 釴 鈠 鎰 鐿 镒 镱 阝 阣 陭 隶 隿 霬 靾 鞥 顡 食 饐 駅 驛 驿 骮 鮨 鯣 鳦 鶂 鶃 鷁 鷊 鷧 鷾 鹝 鹢 黓 齸 益 逸 𥜥]</div>
<div><br></div><div>BTW, IANA considerations have to be normative where they are requirements for IANA to do something, like in the registry. We can't live with just guidelines for what IANA does -- we have to be precise about the process and it has to be normative. See, for example, the BCP47 procedures.</div>
<div><div><span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><pre style="font-size: 1em; "><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre style="font-size: 1em; ">
<span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre style="font-size: 1em; "><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre style="font-size: 1em; ">
<span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre style="font-size: 1em; "><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre style="font-size: 1em; ">
<br></pre></span></pre></span></pre></span></pre></span></pre></span></pre></span>Mark<br>
<br><br><div class="gmail_quote">On Tue, Oct 7, 2008 at 10:27 PM, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
While it is clearly easy to say "remove the normative text from<br>
the Rationale document and put it somewhere else", it has never<br>
been clear to me that we actually agree on which text there is<br>
normative and which is not.<br>
<br>
Please keep in mind while reading this that the document we<br>
casually refer to as "Rationale" actually includes definitions,<br>
background material, and explanations in addition to actual<br>
rationale material. Perhaps we should lengthen the title even<br>
more :-(.<br>
<br>
In his email message of 29 September, Mark proposed a list. I'd<br>
like to review and comment on that list in the hope of putting<br>
this issue into perspective (and, as a consequence, explain why<br>
I'm resisting dealing with it for fear of introducing serious<br>
and further delays).<br>
<br>
The section numbers given are Mark's note and refer to<br>
Rationale-02 and the forthcoming Rationale-03 (no change in<br>
these section numbers). I've added the titles of those<br>
sections (and the leading asterisks) for the convenience of the<br>
WG in reading this note.<br>
<br>
<br>
*** 1.5.2 Terminology about Characters and Character Sets<br>
<br>
Obviously normative definitions.<br>
<br>
*** 1.5.3 DNS-related Terminology<br>
<br>
Obviously normative definitions<br>
<br>
*** 1.5.4 Terminology Specific to IDNA<br>
<br>
This too. But 1.5.1 ("Documents and Standards"), which<br>
defines the terms "IDNA2003" and "IDNA2008", probably<br>
needs to come along as well, especially if 9.1 is<br>
considered normative (see below).<br>
<br>
*** 4. IDNA2008 Document List<br>
<br>
This section is what is referred to elsewhere in the<br>
IETF as a "roadmap". We never consider them normative.<br>
If we considered 1.5.1 to be normative (by it is not on<br>
Mark's list), then we could collapse this document list<br>
into it as part of the definition of what IDNA2008<br>
actually is. But, while it wouldn't be a big deal, that<br>
is the point at which "moving text" turns into "move and<br>
rewrite", which means the WG has more to check and<br>
review.<br>
<br>
*** 5 Permitted Characters: An Inclusion List<br>
<br>
This introductory section is an explanation of the<br>
IDNA2008 model. It is definitely not normative. It<br>
even says that in its second paragraph.<br>
<br>
*** 5.1 A Tiered Model of Permitted Characters and Labels<br>
<br>
While <a href="http://5.1.1." target="_blank">5.1.1.</a>, 5.1.2, and 5.1.3 contain the definitions<br>
of PROTOCOL-VALID, DISALLOWED, and UNASSIGNED,<br>
respectively, the introductory material in 5.1 itself is<br>
clearly explanation and motivation as should be clear<br>
from reading the first paragraph. Even those<br>
definitions are really not normative: the real<br>
definitions are the category-assigning rules in Tables<br>
and those subsections are just explanations of general<br>
theory.<br>
<br>
*** 5.2 Registration Policy<br>
<br>
Others have pointed out that this section doesn't<br>
actually define any policies, it just explains what they<br>
are and why they are important and even explicitly<br>
permits "no policy at all" as a policy. In addition, if<br>
the definition of "normative" is tied to what is needed<br>
to be understood in order to implement Protocol / Bidi/<br>
Tables, this material clearly does not.<br>
<br>
*** 9.1 Summary of Major Changes from IDNA2003<br>
<br>
Whatever this is, I do not believe that it is normative.<br>
See separate note on that subject. On the other hand,<br>
if it were to be treated as normative, then 1.5.5<br>
("Punycode is an Algorithm, not a Name") is probably<br>
necessary to understanding it and hence should be moved<br>
along with it.<br>
<br>
<br>
I don't expect everyone to agree with me on the above analyses.<br>
But my two main points for today are that<br>
<br>
(1) if we decide to start moving "normative" material out of<br>
Rationale and into either Protocol or a separate document, we<br>
are first going to have to agree about what material falls into<br>
the "normative" category. I believe that the analysis above<br>
suggests quite strongly that it is not a simple decision with an<br>
obvious answer.<br>
<br>
(2) If "normative" doesn't really mean that but is, instead, a<br>
placeholder category-term for "definitional, explanatory, and<br>
rationale/motivational material in the Rationale document that<br>
some people think is important and agreed-upon enough to keep,<br>
while the rest of the Rationale document, which they like less,<br>
is permitted to slip through the cracks", then I believe we<br>
should be having a different discussion --really the discussion<br>
associated with Tranche 1, Statement (1.a)-- and not about<br>
"normative material".<br>
<br>
Just my opinion, of course.<br>
<br>
john<br>
<br>
<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</blockquote></div><br></div></div></div>