Subject: Re: [idn] amending [IDNA]?

From: [email-masked]
Date: Fri, 17 Aug 2001 21:07:12 -0700

A mistake is in previous idn-label. This one shall
replace it.  

Liana

idn-label(input, tag-file, input-std, zonefile, idn-name)
{
  tag = find-tag(input, tag-file, input-std);
  switch (tag)
	{
	case USASCII : return(input);  /* a legal DNS string*/
	case NIL: idn-name= 
		uni-compress(input, UNICODE, DEFAULT-ACE);
		return strcat(DEFAULT-ACE, idn-name);
	default:
	 idn-folding(input, input-std, tag, USASCII, output-list);
	 if idn-label-length(output-list) >= MaxLabelLength
	 {	 
		record-label(input, output-list, zonefile, tag);
		idn-truncate-label(output-list, tag);
	 }
	 idn-label-concat(output-list, idn-name);
	 return  strcat(tag, idn-name);
	}

---

From: [email-masked]
Date: Sat, 18 Aug 2001 12:12:19 -0700

After some thinking, I suggest more specific statement
in [IDNA] to explain its relationship with [nameprep]:

On Fri, 17 Aug 2001 18:03:23 -0700 [email-masked] writes:
> Hi, Paul:
> 
> I suggest the following procedure specification 
> adds to [IDNA], this is only an idea, while I have no 
> intention to put proper words in the document.
> 
> [IDNA] is the component of internetionalization of 
> Domain Name system. It contains procedures preparing
> localized domain name representation for DNS and 
> supply display representation for local standard 
> according to DNS registered hostnames.  

[IDNA] implements Unicode codepoint specifications
published in [nameprep]. 

> 
> The IDN-label protocol is:
> 

     if error(tag) 
	{
	fprintf(stderr, "%s %s", idn-name, "illegal characters found in IDN
label.");
	return (ERROR);
	}

> The idn-display protocol is:
> 
> idn-display-code(input, local-std, zonefile, display-string)
> {
>   display-string = NIL;
>   search-zone(input, zonefile, local-std, display-string);
>   if display-string 
> 	return display-string;
> 
>   tag = find-tag (input, tag-file, USASCII);

     if error(tag) 
	{
	fprintf(stderr, "%s %s", input, "WARNING: Error found in DNS label.");
	return (ERROR);
	}

> 	case NIL: return(input); /* legacy name */
> 	case DEFAULT-TAG: 
> 		local-std = UNICODE;
> 		uni-decompress(input, display-string)
> 		return display-string;
> 	default:
> 	 idn-folding(input, USASCII, tag, local-std, 
> display-string);
> 	 if length(inupt) >= MaxLabelLength)  /* truncated */
> 	 	idn-request-fullname(input, output-list, host1, 
> host2);
> 	 return display-string;
> 	} 
> 
> 
delete: > [nameprep] shall be the host for and only deal with
...
delete > for case folding table lookups, and leave exclusion list to be 
delete > checked by idn-label procedure  within a tagged Unicode block.

[nameprep] shall specify availble case folding tables for 
 idn-folding(input, in-std, tag, out-std, out-list) protocol,
and illegal codepoint exclusion shall be implemented in
   tag = find-tag(input, tag-file, input-std)

where tags are script based with naming defined in 
[ISO 639-2/T] and registered with IANA.  

The tags have values:
ERROR		/* contain [nameprep] has Excluded Codepoints */
USASCII		/* [A-Za-z0-9] */
NIL	/* Unicode string with no applicable script label found. */
ZHO	/* Chinese tag */
KOR	/* Korean */
JAP	/* Japanese */
LAT	/* Latin */
...

> 
> I am looking forward for your comments.
> 
> Liana Ye
>

---

From: [email-masked]
Date: Tue, 28 Aug 2001 10:45:44 -0700

Hi,  Harald:

I am thinking a black box procedure, which can
be at a client site, or at local server site depending
on current network configuration.  If it is at client site,
then any existing transport scheme can be used.  If
it is at a server site, then it works like a gateway to
its current local clients using local character code 
standard, such as in Japan and China. 

idn-label(input, tag-file, input-std, zonefile, idn-name)
input: any input stream as a label in input-std
tag-file: script tags where its code blocks of Unicode table are defined,
	this should be registered and tested before distribution.
 example: lat-  block1	block2	block3
	This allows [nameprep] be divided by tags, and allows 
	mixed scripts within a tagged range. 
zonefile: applied to server site; for a client site, it may be default a
cookie?

All these local parameters shall be a part of config package. For
a user, one has to select a tag and a display code standard. 

Liana

On Tue, 28 Aug 2001 15:14:52 +0200 Harald Tveit Alvestrand
<[email-masked]> writes:
> 
> 
> --On 17. august 2001 18:03 -0700 [email-masked] wrote:
> 
> I take it "idn-label" is a procedure to convert an input string into 
> an IDN 
> label for use in the DNS.
> 
> could you please explain a little more where the tag-file, input-std 
> and 
> zonefile arguments to the IDN-label protocol come from?
> 
> are these local parameters at the client, or does this occur at a 
> different 
> place in the system?
> 
> I do not understand.
> 
>              Harald
> 
> 
>