- From: 신정식 <jshin1987@gmail.com>
- Date: Sun, 4 Nov 2012 14:21:11 -0800
- To: Norbert Lindenberg <w3@norbertlindenberg.com>
- Cc: "Ishii, Koji a | Koji | EBJB" <koji.a.ishii@mail.rakuten.com>, Anne van Kesteren <annevk@annevk.nl>, "www-international@w3.org" <www-international@w3.org>
- Message-ID: <CAE1ONj-QghtsGfYfekScoH89YUK4RO0piD0JoMsRZQ_FRsg=fA@mail.gmail.com>
On Sun, Nov 4, 2012 at 12:48 PM, Norbert Lindenberg < w3@norbertlindenberg.com> wrote: > What about email archives on the web? I'd be surprised if there weren't > any that just take the bytes of subjects and bodies of email messages and > stuff them into HTML frames. Even Yahoo Mail and Hotmail did that until a > few years ago. > It's very unfortunate that two major web mail services had been broken in such a horrible way until a few years ago. ;-) It's good for everybody that they have been fixed since. Anyway, I don't think that a potential existence of antiquated/broken email (list) archiving programs is a good justification to keep ISO-2022-KR (and GB-HZ). BTW, when ISO-2022-KR was around in 1990's, the dominant MUA of the time (sendmail) was patched (or combined with MDAs like procmail), at most Korean Unix hosts, to convert incoming emails in ISO-2022-KR to EUC-KR. So, the number of emails kept in ISO-2022-KR at mail(ing list) archives is much smaller than the actual number of emails exchanged in ISO-2022-KR. Jungshik > > Norbert > > > On Nov 4, 2012, at 19:23 , Ishii, Koji a | Koji | EBJB wrote: > > > I think the spec should cover all relevant technologies around W3C, not > only the web pages. I know little about how often ISO-2022-KR is used in > other places than Web, but you should also pay attention to e-mail and > other careers of W3C technologies. > > > > Microsoft once disabled automatic detection of ISO-2022-JP in MS10-090 > for the security concern but turned it on again inMS11-003 due to its bad > impact. As you said and as Kuro confirmed, ISO-2022-JP is still an > important encoding for the W3C to support. > > > > Are you sure ISO-2022-KR and GB-HZ are not, considering all places W3C > technologies are used including e-mail, TV, etc.? > > > > > > Regards, > > Koji > > > > From: Jungshik SHIN (신정식) [mailto:jshin1987@gmail.com] > > Sent: Saturday, November 03, 2012 12:20 PM > > To: Anne van Kesteren > > Cc: www-international@w3.org > > Subject: Re: Encoding Standard at F2F > > > > Hi, > > > > Thank you for the note. > > > > I wonder what consideration has been given to the inclusion of > ISO-2022-KR and GB-HZ, two 7-bit encodings that are extremely rare on the > web (if used at all) and are 'security risks' (in a sense) like other 7-bit > encodings (e.g. UTF-7 that is not included). > > > > We cannot drop ISO-2022-JP lightly because it's still used somewhere > even though it's much less widely used than EUC-JP or Shift-JIS. > > > > OTOH, ISO-2022-KR has never been meant for the web and it's safe to say > that virtually no web page uses it. It's designed for emails (RFC 1557) in > early 1990's and it got out of favor even for emails in late 1990's > because either EUC-KR (later UTF-8) with 8bit ESMTP or EUC-KR with > base64/qp worked just fine. For web pages, there's absolutely no reason to > use ISO-2022-KR from the beginning and it's not used. > > > > For the last 20 years, I've seen web pages (other than test pages) in > that encoding only once or twice. I'm a Korean speaker and I've visited > numerous web pages. > > > > To a slightly less extent, the same should hold for GB-HZ. It started > its life to use in Usenet (and email), but using that on the web does not > make much sense. I can't say about GB-HZ as strongly as about ISO-2022-KR, > but my experience with Chrome development (below) is an indication that > it's virtually unused. > > > > Chrome didn't support either of them until about 2 years ago. They're > added mainly because of http://encoding.spec.whatwg.org/ IIRC. When > neither is supported, I haven't had any complaint from Chrome users. > > > > Jungshik > > > > > > > > 2012. 11. 3. 오전 7:31에 "Anne van Kesteren" <annevk@annevk.nl>님이 작성: > > I joined the I18N WG for an hour or so at their F2F in TPAC to discuss > > http://encoding.spec.whatwg.org/ > > > > We basically went through the document for a high-level overview of > > what it attempts to do. We also concluded it is good enough to publish > > as a FPWD, provided someone in the I18N WG has the time to do the > > switch in style (from green to blue). > > > > Based on feedback from Richard Ishida and Kawabata Taichi during that > > meeting I filed these bugs: > > > > * https://www.w3.org/Bugs/Public/show_bug.cgi?id=19816 > > * https://www.w3.org/Bugs/Public/show_bug.cgi?id=19817 > > > > If there was any other feedback during that session I failed to > > capture I would appreciate if you could help me out. Issues with the > > specification are best recorded in Bugzilla: > > > https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=Encoding > > > > > > -- > > http://annevankesteren.nl/ > > > >
Received on Sunday, 4 November 2012 22:21:39 UTC