> 1) Define an internationalized domain name and host name syntax > for compliant protocols and applications to use. > > [ ] yes > [ ] no
It become more apparent that it is dangerous to into the discussion of internationalized domain names vs internationalized host names. Such discussion is half-technical and half-policy and this group may not have sufficient information to determined what is a considered a valid hostname, and that is subjective to registries. > 2) Define a seven-bit label encoding that legacy protocols and > applications can use to store and represent i18n domain names > as defined data. > > [ ] yes > [ ] no > > 3) Define an UTF-8 label encoding that BCP18-compliant protocols > and applications can use to store and represent i18n domain > names as defined data. > > [ ] yes > [ ] no (2) & (3) are solution-focus statement. And neither have rough consensus nor sufficient fact. I think we should put a scope around this and not specify any solution. Define an IDN label encoding that protocols and applcations can used to store and represent i18n domain names. > 4) Provide proposals to DNSEXT for handling these label encodings > in the DNS service. > > [ ] yes > [ ] no Longer term goal maybe. > 5) Provide guidelines for the protocol and data-formatting groups > to use when they extend their services to tag, store, decipher > and/or display (as necessary) these encodings. > > [ ] yes > [ ] no Care to explain a bit more? > I would also suggest that any further attempts by interested third parties > to redefine the charter without a vote be summarily rejected. We dont do vote in IETF. -James Seng
