Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:
I agree with the fact that we must be able to deliver UTF-8 to IANA. I don't think it necessarily needs to be an I-D. I easily can immagine that you publish an I-D containing just a pointer to an URI and an MD5 for checking.
Can you check into this? It would be nice to say up front what the I-D is for, rather than writing it as "This contains the initial contents of the Registry" and then having the RFC Editor remove the fun part.
2. We have to maintain compatibility with the existing format, which means we must continue to escape the ampersand as & if one should ever find its way into the Registry.As I have said in another mail, I'd agree with the continued need for escaping the sequence "&#x", but I don't see any practical relevance for it; we can simply disallow it. For just "&", it may cause a parsing problem for older software the same way UTF-8 may cause a parsing problem, so I don't see the need to keep escaping it.
The ABNF in 4646 says the ampersand is not a valid character and must be escaped, because it introduces the &#x sequences. I'm feeling lazy. Can someone else verify this, and speak to the impact of allowing a character that we previously did not allow?
-- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14 _______________________________________________ Ltru mailing list Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.