In <3E171FEC(_dot_)5080301(_at_)alex(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
So you're saying that given
List-Owner:
<mailto:%20%3D%3fiso-8859-1%3FQ%3fJ%3dFCrgen%3F%3d%20%3cj(_at_)foo(_dot_)com%3E>
you would construct
I see no non-ASCII characters in there, so I see no problem relevant to
this discussion. Pete Resnick has explained fully why it is irrelevant.
To: %20%3D%3fiso-8859-1%3FQ%3fJ%3dFCrgen%3F%3d%20%3cj(_at_)foo(_dot_)com%3E
I've no idea. I would apply whatever rules are specified by the relevant
RFCs. It that's what results, then it is correct. If it doesn't, then it
isn't.
Good luck.
Now all this could change if IRIs (draft-duerst-iri-02.txt) should get to
the standard stage.
No, it would not change one whit. List-Owner et al. specifically refer
to URIs, and that would remain the case unless and until the defining
RFC is superseded.
You really need to understand the difference between "could" and "would".
I said it "could" change, and you said it "would not" unless and until the
rules for List-Owner changed. In that case it presumably "would". Ergo, it
"could".
Now whilst there is little likelihood that List-Owner will change in that
way, it is highly likely that, if draft-duerst-iri-02.txt is accepted,
_some_ protocols will start to use it, and certainly some future extension
to Usefor might then do so. So it is worth giving a little thought to it
at this stage, because it is probable that a transformation back to URI
format would need be be included in the Usefor gatewaying rules in that
case.
2. Comments may well exist within angle brackets, e.g.:
Return-Path: <(=?us-ascii?q?foo?=)>
But there is no non-ASCII there, so no problem.
Now if I had
Return-Path: <(?-?-?-?)>
where "?-?-?-?" should be regarded as a placeholder for some sensible
comment in Hungarian, Arabic or Chinese, then my proposed workaround
would transform it into
Return-Path: =?iso-8859-1?q?<(=3F-=3F-=3F-=3F>)?=
which, I will grant you, is not a valid Return-Path (I never claimed that
my workaround would work in all cases). It _might_, nevertheless, be
displayed correctly by a tolerant User-Agent. Indeed, I just tried it on
my Netscape, and it did just that.
But before you throw up your hand in horror, you have to account for how
that header came to be in a Usenet article in the first place. It is not
compliant with Usefor (it is not a Usefor-defined header). It is not
supposed even to be a Mail header, except after final RFC 2821 delivery,
and then it would not contain any Non-ASCII character. So how did it get
there? Some perverse poster put it there by hand, perhaps?
No, before you can complain about my workaround, you have to posit some
plausible circumstance in which it could arise. The only case I can
imagine is where someone in the future has published an extension to the
Usefor standard AND there is some gateway that understands Usefor but does
not know how to parse that extension header AND that someone produced such
a header containing some UTF-8 character AND that the gateway produced a
bad guess at how that header should look in email AND that that header
somehow mattered in the email version (even though it was designed as a
Netnews header).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5