> About presentation formats, you argument stands.
> UTF8 form of labels further can be URLEncoded with %xx sequences into
> tripled length of character streams.
> That means "56 x U+AC00 " can be converted into
> 56 x 3 (utf8) x 3 (URLencode) = 504 octets string.
> RFC1035 length restriction does not apply to presentation forms. This is
> your point. right?
Yes.
> But, my question is about utf8 form as protocol elements (wire format
> for future
> application or DNS protocols), not as presentation forms.
> You can find that in IDNA section 6.3.
> Would you make another comments on that section ?
Well if you use raw utf-8 today int the DNS you are limited to
63 octets per label. 255 octets for a domain name. As long as
you continue to use the same label encoding you are limited to
63 octets. YMMV at levels other than the DNS.
However
> THanks.
>
> Soobok Lee
>
>
> [EMAIL PROTECTED] wrote:
>
> > The restrictions have always derived from the DNS wire format.
> > Each individual presentation format will have its own maximum
> > number of octets however just because a string fits within
> > that number of octets doesn't mean that it will be valid.
> >
> > Invalid
> > 0123456789012345678901234567890123456789012345678901234567891234
> >
> > Valid
> > \048\049\050\051\052\053\054\055\056\057\048\049\050\051\052\053
> >
> > Both of the above presentation strings are 64 octets long. Only
> > one is a legal label, both are < 252 octets that you would have
> > to allow to convert a arbitary label from wire format to
> > to RFC 1034 presentation format. Similar things will happen
> > with UTF-8 as a presentation format. Only after you have attempted
> > to covert to wire format can you determine if a arbitarty string
> > of UTF-8 characters that is less than the maximum number of octets
> > long will fit.
> >
> > Mark
> >
> >
>
>
>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
