> [EMAIL PROTECTED] wrote:
>
> >>The restriction orginated from RFC1035 affects all label
> >>creation/validations.
> >>And "octet(ToASCII(X)) <= 63" seems to loosen the restrictions about
> >>8bit labels. That is why i think RFC1035 restriction is about to be
> >>obsoleted.
> >>
> >>
> >
> > There is nothing new with the number of octets in presentation
> > form being greater those presented on the wire. In RFC
> > 1034 0x00 is presented as "\000", 0x5c as "\\" or "\093",
> > 0x2e as "\." or "\046".
> >
> UTF8-form of a label may be used as protocol elements , in addition to
> presentation forms.
> In the latter case, there will be no problem as you said above: just
> display it.
>
> But, in the former case of being used as protocols elements, utf8-form
> label length limit is
> of our concern. IDNA drafts does not rule out that utf-8 form of labels
> may be used as protocol
> elements. This will clairfy my point.
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
> Thanks.
>
> Soobok Lee
>
>
>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
