Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt

Simon,

point taken - the other side of the equation is to try to get the
UNICODE property values to produce stable results using the IDNA2008
algorithms for PVALID, etc. Does anyone know whether U+19DA has
actually been used in any domain names?

v

On Tue, Apr 26, 2011 at 4:28 PM, Simon Josefsson <simon@josefsson.org> wrote:
> "Jiankang Yao" <yaojk@cnnic.cn> writes:
>
>> Dear colleagues,
>>
>> This message starts a two-week WGLC on the draft
>> draft-faltstrom-5892bis-04.txt.
>
> All,
>
> I support publication of a document to clarify IDNA2008's relationship
> to Unicode 6.0 but I believe the content of the above document causes an
> instability for U+19DA which can be avoided.  From my implementer's
> point of view, it seems better to add U+19DA as PVALID in the
> BackwardCompatible (G) category so that we have the property that
> IDNA2008-Unicode5.2(X) = IDNA2008-Unicode6.0(X) for all strings X that
> were permitted by IDNA2008-Unicode5.2.
>
> The above document effectively forbids some strings that were permitted
> before.  I believe this causes a perception of instability in the
> algorithm.  It seems that permitting strings with this code point would
> not cause any problem in practice.  To me that is a strong argument that
> good algorithmical/implementation properties are more important than any
> consideration for this particular code point.  If U+19DA would cause
> operational difficulties, I would be more inclined towards forbidding
> strings that contains it, but I haven't seen those arguments.
>
> This has been brought up before by others, and I have merely been
> convinced by that discussion.  I'm not trying to state this point as
> anything original.  In particular, here are pointers to where Mark Davis
> explains the point:
>
> http://article.gmane.org/gmane.ietf.idnabis/6910
> http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html
>
>> Note: This draft is a document that updates an earlier RFC by stating
>> nothing is to be updated.
>
> That seems wrong.  Technically the document does not claim to update any
> earlier RFC according to the document content (there is no 'Updates:'
> header).  Could you clarify what you mean here?  Is the intention that
> the document will be marked as Updating any earlier RFC or not?
>
> /Simon
> _______________________________________________
> Idna-update mailing list
> Idna-update@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>