--On Sunday, February 9, 2025 16:58 -0800 Rob Sayre <sayrer@xxxxxxxxx> wrote: > On Sun, Feb 9, 2025 at 3:50 PM John C Klensin <john-ietf@xxxxxxx> > wrote: > >> "use of private code points is >> ok if you have some sort of reason". >> > > It seems like that is the reason they exist. This is (U+F8FF).* > It might be a square on your computer, but I can still send it. > > This one is a bit of an artifact, since people mostly just use > stickers/images when they want to use non-standard emoji these days. > > I'll send it to the IETF list here, but not to be a dork. It shows > that these must be dealt with, if you want to interoperate with > HTTP and SMTP etc in the real world. > > The same cannot be said for control characters, surrogates, and > other things eliminated here. One can imagine that a JSON protocol > that needed to interoperate with XML might choose "XML Characters". I see what you are getting at and think that we may have slightly different definitions of "interoperate". Mine includes at least a high expectation that what a recipient or reader sees will be at least a good approximation to what the sender intended to transmit or write. If you send/write U+F8FF anticipating that I will be using that Harvard definition (but without asking first), I think my seeing a little box or some sort of "?"-like rendering is a failure, although not as serious a failure as if I saw a frowning face and construed it as U+2639 or, for that matter, U+1F615. In those first two cases, I would at least have a good clue that my system didn't understand that particular private use; in the second two, no clue. In yours, as I understand it, it is sufficient that, if U+F8FF went into the message/ onto the web page and was visible to the MUA or browser at the other end, that is ok -- and, at least nothing in transit messed it up and turned the code point into something else entirely. I'm not going to disagree with that... just different definitions/ perspectives. However, I think it gets me back to the point I tried to make in my earlier note: because the recipient/reader may not see what was intended -- whether they see an indication of an unrecognized code point and some symbol from an entirely separate private agreement -- I think a recommendation that it is ok to use private code points must be accompanied by text that explains the possible problems and risks. Or the document needs a good and very clear explanation that these three subsets are safe to transmit (or use on web pages) because it is unlikely that anything in transit will mess them up in an attempt to fix Unicode errors but that binding of code points to any sort of rendering or interpretation considerations is Someone Else's Problem. john > > thanks, > Rob > > * https://hea-www.harvard.edu/~fine/OSX/unicode_apple_logo.html -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
