Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

From: liana Ye <[email-masked]>
Date: Fri, 31 May 2002 11:43:01 -0700

Eric:

Now that I can see where your stand comes from.  7-bit vs. 
8-bit interpretation can be compared at many points of 
our internet transmission, or we say at many layers our
communication model.  

In the old days, the layers were not very clear to many, and
we handle 8-bit data at keyboard input level, which later 
continues from the wire of keyboards to the wire of internet.  

At this point, we trying to use only 7-bit interpretation as the
standard to insure the stability and easy handling of internet
security, from the bottom up, while trying to conver the 8-bit
data onto the 7-bit label at some levels agreeable to 
implementors, service providers and the users.  

An 8-bit interpretation to be a standard is only possible 
after we can get 7-bit IDN implemented and proved to be 
stable.  Let us leave the 8-bit interpretation undefined for 
now, so that we can move on.

Liana

On Fri, 31 May 2002 12:29:14 -0500 "Eric A. Hall" <[email-masked]>
writes:
> 
> John C Klensin wrote:
> 
> > My problem is that I don't know how to tell the three cases
> > apart (except by looking at RR type or Class definitions).  If
> > you believe [...]
> 
> What I believe is that DNS systems store and exchange raw octet 
> values.
> 
> Secondary to that point, the only time that ASCII enters into the 
> equation
> is when the octet values need to be interpreted, as in: (1) the 
> 7-bit
> values are rendered for display, and (2) the 7-bit values in the A-Z 
> and
> a-z ranges from ASCII are compared. In all other cases, the data is
> treated as simple octet values. This includes ASCII character values 
> (NB
> the case-specific storage rules), the non-character ASCII values, 
> and the
> eight-bit non-interpreted codes.
> 
> Tertiary to that point, the rules for hostnames are recommendations 
> which
> act as a higher-layer octet-range mask, but this does not change the
> storage and transfer formats, nor does it change the interpretation 
> rules.
> Instead it only defines a reasonable subset of characters with high
> probabilities of successful interpretation.
> 
> In short, all code values in the DNS database and message are 
> treated as
> octets. If a domain name contains a seven-bit code, that value must 
> be
> treated as a precise ASCII character. If a domain contains an 
> eight-bit
> code, then that code must be treated as undefined data. If the 
> domain name
> needs to be compared with another domain name, all of the codes must 
> be
> treated as eight-bit values, with the exception of the A-Z and a-z 
> ranges.
> 
> I also believe that it is entirely possible for people to think way 
> too
> much about this.
> 
> Finally, I also believe that any subsequent discussion on this 
> matter
> should be directed to namedroppers. This WG is not the proper forum 
> for
> any advancement of this discussion.
> 
> -- 
> Eric A. Hall                                        
> http://www.ehsco.com/
> Internet Core Protocols          
> http://www.oreilly.com/catalog/coreprot/
>

---

From: [email-masked]
Date: Sat, 01 Jun 2002 10:17:11 +1000

Below is the wire to presentation table from RFC 1034 / 1035
	for label octets.  BIND also escapses '"' but that is not
	strictly required.

     00 \000  01 \001  02 \002  03 \003  04 \004  05 \005  06 \006  07 \007
     08 \008  09 \009  0a \010  0b \011  0c \012  0d \013  0e \014  0f \015
     10 \016  11 \017  12 \018  13 \019  14 \020  15 \021  16 \022  17 \023
     18 \024  19 \025  1a \026  1b \027  1c \028  1d \029  1e \030  1f \031
     20 \032  21  !    22  "    23  #    24 \$    25  %    26  &    27  '
     28 \(    29 \)    2a  *    2b  +    2c  ,    2d  -    2e  \.    2f /
     30  0    31  1    32  2    33  3    34  4    35  5    36  6    37  7
     38  8    39  9    3a  :    3b  \;   3c  <    3d  =    3e  >    3f  ?
     40 \@    41  A    42  B    43  C    44  D    45  E    46  F    47  G
     48  H    49  I    4a  J    4b  K    4c  L    4d  M    4e  N    4f  O
     50  P    51  Q    52  R    53  S    54  T    55  U    56  V    57  W
     58  X    59  Y    5a  Z    5b  [    5c \\    5d  ]    5e  ^    5f  _
     60  `    61  a    62  b    63  c    64  d    65  e    66  f    67  g
     68  h    69  i    6a  j    6b  k    6c  l    6d  m    6e  n    6f  o
     70  p    71  q    72  r    73  s    74  t    75  u    76  v    77  w
     78  x    79  y    7a  z    7b  {    7c  |    7d  }    7e  ~    7f \127
     80 \128  81 \129  82 \130  83 \131  84 \132  85 \133  86 \134  87 \135
     88 \136  89 \137  8a \138  8b \139  8c \140  8d \141  8e \142  8f \143
     90 \144  91 \145  92 \146  93 \147  94 \148  95 \149  96 \150  97 \151
     98 \152  99 \153  9a \154  9b \155  9c \156  9d \157  9e \158  9f \159
     a0 \160  a1 \161  a2 \162  a3 \163  a4 \164  a5 \165  a6 \166  a7 \167
     a8 \168  a9 \169  aa \170  ab \171  ac \172  ad \173  ae \174  af \175
     b0 \176  b1 \177  b2 \178  b3 \179  b4 \180  b5 \181  b6 \182  b7 \183
     b8 \184  b9 \185  ba \186  bb \187  bc \188  bd \189  be \190  bf \191
     c0 \192  c1 \193  c2 \194  c3 \195  c4 \196  c5 \197  c6 \198  c7 \199
     c8 \200  c9 \201  ca \202  cb \203  cc \204  cd \205  ce \206  cf \207
     d0 \208  d1 \209  d2 \210  d3 \211  d4 \212  d5 \213  d6 \214  d7 \215
     d8 \216  d9 \217  da \218  db \219  dc \220  dd \221  de \222  df \223
     e0 \224  e1 \225  e2 \226  e3 \227  e4 \228  e5 \229  e6 \230  e7 \231
     e8 \232  e9 \233  ea \234  eb \235  ec \236  ed \237  ee \238  ef \239
     f0 \240  f1 \241  f2 \242  f3 \243  f4 \244  f5 \245  f6 \246  f7 \247
     f8 \248  f9 \249  fa \250  fb \251  fc \252  fd \253  fe \254  ff \255

	Below is the table use to compare label octets in wire form by
	indexing into the table and then comparing the resulting mappings.
	As it maps to "lowercase" it is also the DNSSEC mapping table.

	two labels are equal if there lengths are equal and
	there mapped values are equal.

	e.g.
		/* compare uncompressed label */
	int
	equal(unsigned char *l1, unsigned char *l2) {
		int i;
		/* uncompressed labels? */
		INSIST(*l1 <= 63 && *l2 <= 63); /* caller is broken */
		if (*l1 != *l2)
			return (0);
		for (i = 1; i <= l1[0]; i++)
			if (dnssec[l1[i]] != dnssec[l2[i]])
				return(0);
		return (1);
	}

char dnssec[] = {
        0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
        0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
        0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
        0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
        0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
        0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
        0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
        0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
        0x40, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
        0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
        0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77,
        0x78, 0x79, 0x7a, 0x5b, 0x5c, 0x5d, 0x5e, 0x5f,
        0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
        0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
        0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77,
        0x78, 0x79, 0x7a, 0x7b, 0x7c, 0x7d, 0x7e, 0x7f,
        0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
        0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f,
        0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97,
        0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f,
        0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7,
        0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf,
        0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7,
        0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf,
        0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7,
        0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf,
        0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7,
        0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf,
        0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7,
        0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef,
        0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7,
        0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff
};

	Whether you like the wording of RFC 1034/1035
	the real world implements RFC 1034/1035 this way.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]