<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-AU link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Shawn,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I definitely agree with you, context rules should not be applied
on lookup, I hope no one interpreted my post to think I was saying that. What I
am saying is that I don’t think the rules should exist (as rules) at all, then
if they must stay, a whole bunch of clarifying questions which hopefully
someone can answer.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Of great importance is the script restriction in the joiner rule
that IS applied on lookup.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>c.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Shawn Steele
[mailto:Shawn.Steele@microsoft.com] <br>
<b>Sent:</b> Friday, 17 July 2009 7:35 AM<br>
<b>To:</b> Mark Davis </span><span lang=EN-US style='font-size:10.0pt;
font-family:"Arial Unicode MS","sans-serif"'>⌛</span><span lang=EN-US
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>; Chris Wright<br>
<b>Cc:</b> idna-update@alvestrand.no<br>
<b>Subject:</b> RE: Context Rules - with apologies for the long email<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks Chris for providing input, more perspectives is always
good </span><span lang=EN-US style='font-size:11.0pt;font-family:Wingdings;
color:#1F497D'>J</span><span lang=EN-US style='font-size:11.0pt;font-family:
"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I prefer the lookup rules to be more relaxed than the registration
rules. If the name isn’t registered, then it won’t work, I don’t think
the rules should be required on lookup just to force registry best practices.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>These rules are also more difficult to update than data (if they
might require code changes), particularly when multiple clients/versions that
need lookup are taken into account. Servicing & testing those kinds
of changes in say XP, Vista, Server 2003, Win7, etc., can be very
expensive. Especially if we then decide a new rule needs added (maybe for
new code points), or a rule needs tweaked for some edge case.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-Shawn<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> idna-update-bounces@alvestrand.no
[mailto:idna-update-bounces@alvestrand.no] <b>On Behalf Of </b>Mark Davis ?<br>
<b>Sent:</b> Thursday, July 16, 2009 9:01<br>
<b>To:</b> Chris Wright<br>
<b>Cc:</b> idna-update@alvestrand.no<br>
<b>Subject:</b> Re: Context Rules - with apologies for the long email<o:p></o:p></span></p>
</div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US><br clear=all>
Mark<o:p></o:p></span></p>
<div>
<p class=MsoNormal><span lang=EN-US>On Wed, Jul 15, 2009 at 23:43, Chris Wright
<<a href="mailto:chris@ausregistry.com.au">chris@ausregistry.com.au</a>>
wrote:<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US>As this is my first post to this list, a
very quick background, for setting the context purpose only:<br>
- AusRegistry is the .au domain name registry. Our registry software is
in use in several other TLD registries many of which are eagerly awaiting their
ccTLD IDNs from ICANN<br>
- We have been following this list for a the last 12 months or so<br>
- We have spent the last almost 12 months implementing IDNs (IDN 2008) in
our registry software, implemented all of the current drafts with the exception
of mappings<br>
- We have, especially focused on Arabic IDNs and IDN 2008 (see Arabic
comments further down)<br>
- Now have a fully working initial implementation that includes
configurable elements to address registry policy controls such as generation,
bundling and blocking of variants etc<br>
<br>
On Context Rules:<br>
<br>
As implementers we found that the current definitions are a little bit
ambiguous and redundant in some places, the pseudo code can be confusing to
follow and in most cases we returned to the descriptions to guess what was
intended. We would be happy to take a shot at improving these, however we have
some broader concerns with context rules that we would like to address first.<o:p></o:p></span></p>
<div>
<p class=MsoNormal><span lang=EN-US><br>
I agree about the former; I also think that we have too many CONTEXT* items in
the first place, and that we should reduce them to what is required before
trying to fix the pseudocode.<br>
<br>
<o:p></o:p></span></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal><span lang=EN-US><br>
<br>
Appendix A.1. HYPHEN-MINUS<br>
<br>
In the protocol document it states in <a href="http://4.2.3.1" target="_blank">4.2.3.1</a>:<br>
<br>
> The Unicode string MUST NOT contain "--" (two consecutive
hyphens) in<br>
> the third and fourth character positions.<br>
<br>
This is an explicit disallow of that character in those positions for all
labels (ALL CONTEXTS), yet this context rule restricts the use of hyphens in
the first and last position for all labels (ALL CONTEXTS) i.e. this context
rule appears to have no specific context. Given this, why isn't this just
another protocol rule similar to the one above?<br>
<br>
Appendix A.2 ZERO WIDTH NON-JOINER<br>
<br>
In the regular expression you reference 'Joining_Type:L' which we initially
assumed to mean the Unicode Joining type property of the character must be L as
described in <a href="http://www.unicode.org/Public/UNIDATA/ArabicShaping.txt"
target="_blank">http://www.unicode.org/Public/UNIDATA/ArabicShaping.txt</a>,
however upon further investigation there are no code points with that property
value. It wasn't until we found <a href="http://unicode.org/review/pr-96.html"
target="_blank">http://unicode.org/review/pr-96.html</a> which appears to
clarify what was trying to be achieved (we think), that it became clear to us
that this rule should actually include type D as well. Is this what was
intended?<o:p></o:p></span></p>
</blockquote>
<div>
<p class=MsoNormal><span lang=EN-US><br>
I think the intent was to match <a
href="http://www.unicode.org/reports/tr31/tr31-10.html#Layout_and_Format_Control_Characters">http://www.unicode.org/reports/tr31/tr31-10.html#Layout_and_Format_Control_Characters</a>,
table A1.<br>
<br>
(Note that there is a correction there to fix the dual joining language. That
is, the regex was fine, but the textual explanation was in error. This is the
draft update for Unicode 5.2, due in October.)<br>
<o:p></o:p></span></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal><span lang=EN-US><br>
<br>
Additionally if you scan the Unicode code table for all code points with the
joining type property of T,L,R and D there are many more scripts than the 3
listed in the context rule. There are PVALID code points in the following
scripts:<br>
<br>
Gujarati, Lepcha, Rejang, Kharoshthi, Devanagari, Tamil, Malayalam, Tagalog,
Syloti_Nagri, Gurmukhi, Sinhala, Lao, Hanunoo, Kayah_Li, Bengali, Thai,
Myanmar, Ethiopic, Buhid, Cyrillic, Tibetan, Inherited, Nko, Thaana, Oriya,
Telugu, Kannada, Limbu, Buginese, Sundanese, Arabic, Khmer, Mongolian,
Saurashtra, Syriac, Hebrew, Tagbanwa, Balinese, Cham<br>
<br>
If the Unicode consortium sees fit to define this rule without referring to the
scripts at all (as in the second link above) why does the protocol restrict
this further? Most registries will not allow the combining of characters of
different scripts together in the same label anyway, as recommended by ICANN
and I thought in the draft documents as well (at some point)<o:p></o:p></span></p>
</blockquote>
<div>
<p class=MsoNormal><span lang=EN-US>In practice, while the transparent
characters can be almost anything, the preceding and following characters are
limited, eg.<br>
<br>
<a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5b">http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[</a>\p{Joining_Type%3DDual_Joining}\p{Joining_Type%3DRight_Joining}]<br>
<br>
However, you have a good point; I don't think there is need to restrict the
scripts. <br>
<o:p></o:p></span></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal><span lang=EN-US><br>
<br>
Given that this rule is to be applied on lookup we are concerned that the IDNA
protocol may end up restricting scripts/languages that have not yet been
considered.<br>
<br>
Appendix A.3 ZERO WIDTH JOINER<br>
<br>
Given its on lookup, same argument as the last 2 paragraphs of A.2<br>
<br>
Appendix A.4. MIDDLE DOT<br>
<br>
No specific comments on this rule other than it is really policy as discussed
below<br>
<br>
Appendix A.5 GREEK LOWER NUMERAL SIGN<br>
<br>
The script function is defined in tables-05, page 13 as:<br>
<br>
> Script(cp) return the name of the Script cp is of<br>
<br>
Given this, my reading of this rule prohibits the use of GREEK LOWER NUMERAL
SIGN in any domain that does not contain code points with the 'Greek' script
property. This means code points with the script property of 'Common' (for
example) cannot be used in these labels, that would mean, for example, this
context rule would prohibit a registrant from using a hyphen to separate the
words of their domain, is this really what was intended?<br>
<br>
Appendix A.6. MODIFIER LETTER PRIME<br>
<br>
Similar problem to A.5, all characters must be script common (lower case c
common). Additionally, this context rule is intended to be applied to labels
containing MODIFIER LETTER PRIME, it states that all characters must be in the
script of 'Greek' however MODIFIER LETTER PRIME is actually in script 'Common'
thus this rule should always fail!<br>
<br>
Appendix A.7. COMBINING CYRILLIC TITLO<br>
<br>
As per A.5.<br>
<br>
Appendix A.8 HEBREW PUNCTUATION GERESH<br>
<br>
This one is hard to decipher, I could argue that (given the indentation):<br>
<br>
Assuming H is Hebrew, C is Chinese and P is the punctuation then the label
HHHPCCCCHP would satisfy the rule<br>
<br>
The definition of LastChar and/or .eq. is ambiguous at best I interpret these
lines<br>
<br>
If Script(Before(cp)) .eq. Hebrew And<br>
LastChar .eq. cp Then True;<br>
<br>
To say, if there is HPG where the script of the code point before it is Hebrew,
and the LastChar is also a HPG then True but Im pretty sure that is not what
was intended. I think the .eq. in this case is meant to say that is the
LastChar the code point being tested or is it 'equal to' the code point being
tested not is the 'last code point' equal to (ie the same code point value) as
the code point being tested. It's even difficult to explain correctly. Also the
indentation is hard to follow, is it actually meant to mean anything or is it
just for visual purposes, I believe what was intended is something more like:<br>
<br>
IsLast(cp) True if code point is the last code point in the label<br>
<br>
False;<br>
If Script(Before(cp)) .eq. Hebrew And IsLast(cp) Then True;<br>
If Script(Before(cp)) .eq. Hebrew And<br>
Script(After(cp)) .eq. Hebrew Then True;<br>
<br>
Additionally the rule does not allow this character to appear at the start of
the label, because of the definition of the Before function, was this intended?
Regardless this is fine, however inconsistent with A.10. and A.11., which
explicitly states this requirement and then implements a rule to prevent it.<br>
<br>
Appendix A.9. HEBREW PUNCTUATION GERSHAYIM<br>
<br>
As per A.8.<br>
<br>
Appendix A.10. IDEOGRAPHIC ITERATION MARK;<br>
<br>
See final paragraph of A.8.<br>
<br>
Appendix A.11. VERTICAL IDEOGRAPHIC ITERATION MARK<br>
<br>
See final paragraph of A.8.<br>
<br>
Appendix A.12. KATAKANA MIDDLE DOT<br>
<br>
Similar to the case in A.8. this rule implicitly uses Before and After to state
that the code point cannot appear at the beginning and end of the label is this
intended? Why not explicitly state it like in A.10 and A.11<br>
<br>
Appendix A.13. ARABIC-INDIC DIGITS & Appendix A.14. EXTENDED
ARABIC-INDIC DIGITS<br>
<br>
Quoting BIDI draft document<br>
<br>
BIDI description in section 2<br>
<br>
> A label containing a character of type R, AL or AN MUST satisfy all 7<br>
> of the rules below.<br>
<br>
AND BIDI rule number 5 of section 2<br>
<br>
> 5. If an EN is present, no AN may be present, and vice versa.<br>
<br>
Given the above, these context rules are not needed, as the BIDI rules
explicitly prohibit this from happening anyway!<o:p></o:p></span></p>
</blockquote>
<div>
<p class=MsoNormal><span lang=EN-US><br>
For essentially all of the above, I don't think we want them to be context at
all. I'll put out a separate note.<br>
<o:p></o:p></span></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal><span lang=EN-US><br>
<br>
<br>
ISSUES WITH CONTEXT RULES THAT ARE FOR REGISTRATION ONLY<br>
<br>
Firstly I'd like to support Shawn Steele in his view that these should be
described more like:<br>
<br>
> Maybe instead of "Lookup: true/false" it could be something like
"Context: Registration Only" or "Context: Registration and
Lookup".<br>
<br>
We assume that the audience of these rules is for humans and this clarifies
things very clearly.<br>
<br>
However, I'd really like to ask what is the purpose of Registration only
context rules. Given that these rules won't stop domains being looked up as
soon as a registry disagrees with one of the registration only rules, they will
simply stop applying it!. For example the context rule concerning 'modifier
letter prime' discussed above which excludes a hyphen or digits, why would I as
a registry operator want to apply it as written? If I allow hyphens to be used
in those names, the domain names will still work when looked up. This leads me
to a greater discussion about how registration only context rules are really
just policy decisions!<br>
<br>
I acknowledge and welcome the effort put in by all, and I think they are
important aspects of IDNs that should be documented and circulated, however, I
feel they are only implemented by registries and thus should only be
recommendations for best common practices for registries, not enforced parts of
the standard/protocol/<insert the right word here>. The document should
be educating the registries about the potential issues with certain characters
that they may allow but that should be it. Not all languages have been
represented during the development of these rules, what if some language that
has not been considered yet requires to use this 'modifier letter prime' (or
some other focus of another context rule) and we have now FORCED with the
protocol that they couldn't, when really it should just be a recommendation for
the zone administrator (registry) about a business rule they should apply to
registrations. I believe there will potentially be many more 'context' style
rule<br>
s that will need to be developed as we move forward, and these will not
become part of the standards documents, just be rules that are implemented by
registries.<br>
<br>
As an example, if we look at the 'Yiddish' rules used by the .SE registry
(documented here <a
href="http://iana.org/domains/idn-tables/tables/se_yi_1.0.html" target="_blank">http://iana.org/domains/idn-tables/tables/se_yi_1.0.html</a>)
they state that certain combining marks are only allowed to be used with
certain base characters (i.e. in a given context), these are also 'context'
rules but not things that should be part of the standard. As long as the code
points are PVALID, and if this means some code points become PVALID by
exception then so be it, but then leave it the registries to define the
contexts in which they actually can and can't be used.<br>
<br>
A BCP document that points out the issues with each item context rules are
trying to address, shows some examples, and then recommends that zone
administrators produce policy requirements to prohibit certain registrations
using context style rules should be sufficient, and is the most flexible
approach moving forward. No zone administrator in their right mind would do
anything to risk their namespace being branded as unsafe etc. I also believe
that lower levels of DNS hierarchy will never apply 'registration only' context
rules!<o:p></o:p></span></p>
</blockquote>
<div>
<p class=MsoNormal><span lang=EN-US><br>
I agree; I think unless the BIDI and CONTEXT rules are required in the lookup
procedure, they might as well just be guidelines for registrars.<br>
<o:p></o:p></span></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>
<p class=MsoNormal><span lang=EN-US><br>
<br>
Thanks<br>
<br>
Chris Wright<br>
Chief Technology Officer<br>
AusRegistry Pty Ltd<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><o:p></o:p></span></p>
</blockquote>
</div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
</body>
</html>