Charles Lindsey wrote:
In <3E03AB9A(_dot_)5070001(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
List-Owner:
<mailto:%3D%3fiso-8859-1%3FQ%3fJ%3dFCrgen%3F%3d%20%3cj(_at_)foo(_dot_)com%3E?Subject=list>
[...]
As mentioned in the earlier message, it's URI-encoded as required by
RFC 2368 (section 2). Depending on UA, you may be able to see it
simply by positioning your cursor over the mailto URI (at least
that works with Mozilla 1.2.1).
Yes, but if the URI is decoded URI-wise, then I see nothing which suggests
that it should then be further subjected to RFC 2047 decoding. If it is a
structured header (I guess List-Owner is structured) then RFC 2047
instructs you to identify comments and phrases within it. In your example
there are none.
There most certainly is a phrase, part of the mailbox. Please read RFC 2368
section 2 as referenced above. Here is a pertinent excerpt:
Following the syntax conventions of RFC 1738 [RFC1738], a "mailto"
URL has the form:
mailtoURL = "mailto:"; [ to ] [ headers ]
to = #mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *urlc
hvalue = *urlc
"#mailbox" is as specified in RFC 822 [RFC822]. This means that it
consists of zero or more comma-separated mail addresses, possibly
including "phrase" and "comment" components.
Please note the last part of the last sentence quoted above!
RFC 2369 section 2 gives the syntax (but no BNF) for List- headers,
which are unquestionably structured [a comma-separated list (structure)
of angle bracketed (more structure) URIs (yet more structure)]. Section
3.5 gives List-Owner examples, all of which have comments.
And of course RFC 822 gives the formal mailbox ABNF:
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
^^^^^^
RFC 2047 does apply to a phrase within a structured header (technically,
there should probably be another %20 between the colon and the first
%3D in my example).
The point is that (via mailto URLs at least) phrases and/or comments
which could potentially contain RFC 2047 encoded-words may appear
within angle brackets (as in the RFC 2369 List- headers), so your
suggestion of ignoring anything within angle brackets when looking
for potential encoded-words leads to failure to recognize encoded-words.
That might be acceptable for display (though it completely misses the
point of RFC 2047 encoding in the first place, which is precisely for
display), but it could lead to gross errors if such a scheme were used
in a gateway.