RE: [idn] IDNA and Control codes (0-1F) and 7F

["Krall, Gary" <gkrall@verisign.com>]

Jefsey:

Our SDK (which includes both C as well as a Java implementation) is open
sourced and covered under BSD licensing provisions.  For the specific
information about our library you may go to:  

http://www.verisign.com/products-services/naming-and-directory-services/nami
ng-services/internationalized-domain-names/idn-registrars/page_001408.html

Additionally for a list of current environments which support IDNA (includes
both applications as well as programming languages) you may go to:

http://www.verisign.com/products-services/naming-and-directory-services/nami
ng-services/internationalized-domain-names/page_002201.html

Hope this helps.

Gary.

-----Original Message-----
From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com]
Sent: Tuesday, September 14, 2004 3:32 PM
To: Krall, Gary; 'IETF idn working group'
Subject: RE: [idn] IDNA and Control codes (0-1F) and 7F


Dear Gary,
were can this DSK be found. Or is it proprietary?
thanks
jfc morfin


At 22:30 14/09/2004, Krall, Gary wrote:

>All:
>
>Just as an fyi, the C library in the Verisign SDK ("Xcode") has the
>UseSTD3ASCIIRules  rule set by default.  It is a compile switch option
which
>can be changed in the library's configuration file.
>
>Also note that the library does not accept null characters embedded in
input
>strings regardless of how this flag is set. Control characters other than
>null will pass through as expected without the std3 flag set.
>
>Gary.
>
>-----Original Message-----
>From: Adam M. Costello [mailto:idn.amc+0@nicemice.net.RemoveThisWord]
>Sent: Monday, September 13, 2004 11:58 PM
>To: IETF idn working group
>Subject: Re: [idn] IDNA and Control codes (0-1F) and 7F
>
>
>Michel Suignard <michelsu@windows.microsoft.com> wrote:
>
> > By excluding table C.2.1 from the StringPrep profile used by IDNA, the
> > ToASCII operation allows all C0 control codes and 7F in its default
> > mode (UseSTD3ASCIIRules flag unset).
>
>As Paul said, there is no default mode.  It is up to the application
>to decide whether to set UseSTD3ASCIIRules.  Of course a library could
>make one mode or the other the default, and it is free to choose either
>mode to be the default.  A library could also, I suppose, implement only
>one mode or the other, in which case I guess it would be an incomplete
>conformant implementation of ToASCII.
>
> > This is rather troublesome as these control codes, especially the 00
> > value, may create all sorts of issues for run time libraries that use
> > zero as string terminator on input.
>
>If the programming environment customarily uses a string representation
>that does not allow embedded NULs to be represented, then it will be a
>moot point whether your ToASCII implementation handles NUL correctly,
>because it cannot be tested anyway.  You can reasonably claim that it's
>not your IDN library that's incomplete, but the programming environment
>that's incomplete.
>
>Note that ToASCII and ToUnicode will never try to output an embedded NUL
>character if they never receive an embedded NUL character as input.
>
>For an example of a C library that handles embedded NULs, see GNU
>libidn:
>
>http://www.gnu.org/software/libidn/
>
> > I understand the value of allowing all ASCII non control characters
> > but allowing by default the control characters in a ToASCII function
> > seems to open the door for all sorts of abuse and security risks.
>
>ToASCII and ToUnicode never introduce control characters; they output
>only those control characters that were already present in the input.
>If you consider control characters to be dangerous, then I would think
>you'd want to reject them as early as possible, before you even get to
>calling ToASCII or ToUnicode.  One you have control-code-free strings,
>ToASCII and ToUnicode will preserve that property.
>
> > Would a library that by default only allow the range 20-7E be still
> > considered conformant?
>
>If you want to claim to have a complete implementation of ToASCII, then
>I think it needs to be possible to pass control characters through.
>But it needn't be the default mode.  If you want to add your own
>AllowControlChars flag that is unset by default, I see no problem with
>that.  The spec standardizes the function (input --> output), but not
>the interface.
>
>AMC
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.752 / Virus Database: 503 - Release Date: 03/09/2004