Talk:UTF-7

message: What exactly is encoded as Base64 between the + and the -? Is it UTF-16? -- Timwi 02:37, 21 Dec 2003 (UTC)
replies: text: Yeah: "Unicode is encoded using Modified Base64 by first converting Unicode 16-bit quantities to an octet stream (with the most significant octet first). Text with an odd number of octets is ill-formed." (from the RFC) CGS 01:04, 23 Dec 2003 (UTC)
replies: text:  Thanks. Fixed the article. -- Timwi 04:16, 23 Dec 2003 (UTC)
replies: text:  Unfortunately it seems the UTF-7 standard was not updated to clarify the situation with regard to unicode 2.0 (even though it cites version 2.0 of the unicode standard). It treats UCS-2 as synonymous with "16-bit unicode" and neither explicitly allows nor explicitly forbids use of UTF-16 surrogates. It would be interesting to know how practical implementations handle this. Plugwash (talk) 02:41, 19 August 2011 (UTC)
thread_title:  Technical question 

message: Thanks for spotting that "i" :-) -- Timwi 02:00, 15 Feb 2004 (UTC)
thread_title:  Thanks 

message: "UTF-7 allows multiple representations of the same source string ..."
So what? The security section says nothing about security. IMO it should be completely deleted. bungalo (talk) 09:10, 12 October 2009 (UTC)
replies: text: The problem with character encodings that allow multiple representations of the same string is that if and when someone attempts to do validation some representations are likely to get missed. This can allow dangerous strings to be slipped past the validation. UTF-8 "quoted printable" has the same issue though so the second part of that section was bullshit (i've fixed it up now). Ultimately it's not a problem as long as the developers of apps are aware they must decode before validating. Plugwash (talk) 22:31, 14 October 2009 (UTC)
thread_title:  Security 

message: The best I could find in RFC 821
         The mail data may contain any of the 128 ASCII characters.  All
         characters are to be delivered to the recipient's mailbox
         including format effectors and other control characters.  If
         the transmission channel provides an 8-bit byte (octets) data
         stream, the 7-bit ASCII codes are transmitted right justified
         in the octets with the high order bits cleared to zero
Furthermore in a couple of the apendicies on transmission through various mediums it says that "The SMTP data is 7-bit ASCII characters."
So while I can't find anything explicitly forbidding  higher valued characters it certainly implies that support for them cannot be relied on. Therefore any sender who wants to make sure thier mail gets through unmolested needs to avoid going beyond 7-bit ascii.
If we look at RFC 2821 (the replacement for RFC 821) we see the following statement
   The content
   is textual in nature, expressed using the US-ASCII repertoire [1].
   Although SMTP extensions (such as "8BITMIME" [20]) may relax this
   restriction for the content body, the content headers are always
   encoded using the US-ASCII repertoire.
-- Plugwash (talk) 01:10, 15 December 2009 (UTC)
replies: text: So, you state that “the transmission format is US-ASCII”, although it “may [be] relax[ed]”. IMHO this is nothing but an oxymoron and gibberish — if format was defined as US-ASCII, then high-bit set would not be allowed by definition. If high-bit set are possible (even though not guaranteed to treated in an expected way), then “the transmission format” is something broader than US-ASCII, by definition of the latter. Please, add citations as necessary or remove mentioning of “the transmission format” at all; just reverting my citation request for a controversial unreferenced statement is an edit at the edge of vandalism. Incnis Mrsi (talk) 04:53, 15 December 2009 (UTC)
thread_title:  limitation to ascii 

message: I propose to delete this section. Not only are "UTF-5" and "UTF-6" unimplemented vaporware (they were early entries in an IDNA competition which Punycode ultimately won), but they have nothing whatsoever to do with UTF-7. Doug Ewell 19:49, 22 May 2010 (UTC)
replies: text: Done, it was anyway completely bogus, these encodings are clearly related to "Punycode", and not intended for any other purposes. Besides it's enough to have this cruft in one article, not here. –89.204.137.230 (talk) 21:59, 10 June 2011 (UTC)
thread_title:  Not yet developed: UTF-6 and UTF-5 

message: The paragraph beginning "Confusingly, Microsoft..." refers to an erroneous piece of .NET documentation from 2011. Microsoft has corrected the page  so that it no longer refers to UTF-7. Since the only remaining purpose for leaving this paragraph in the article is to try to embarrass Microsoft for an earlier mistake, I suggest deleting it. Doug Ewell (talk) 17:58, 14 November 2015 (UTC)
replies: text: Done, thanks for pointing that out. BabelStone (talk) 18:59, 14 November 2015 (UTC)
thread_title:  Microsoft doesn't say that any more 

message: Near the top of the article is data about how few web sites use UTF-7, but I don't understand how this is relevant to the topic. Most of the rest of the discussion talks about UTF-7 in the context of e-mail, where it originated. I am minded to move the web-related sentences further down the page into their own section, unless someone suggests otherwise. Stephen lamppost (talk) 00:52, 10 March 2020 (UTC)
replies: text: This is now done.Stephen lamppost (talk) 01:20, 14 March 2020 (UTC)
thread_title:  Web relevance