ietf-822
[Top] [All Lists]

Re: Interpretation of RFC 2047

2002-12-24 10:43:51

Pete Resnick wrote:
On 12/24/02 at 9:06 AM -0500, Bruce Lilly wrote:

There most certainly is a phrase, part of the mailbox.


No, sorry, it doesn't work that way. Just because 2368 (via 1738) specifies that some structured part of an encoded URL follows 822/2822 syntax for "mailbox" does not mean that a mail header field that contains such a URL therefore contains a mailbox. The parser for 822/2822/2047 does not know about URL parsing and cannot get past the "%" encoded bits. There is no intervening 1738 parser.

That depends on the context. In the case of the List-Owner example and
a number of fairly widely-used MUAs, the URL is properly decoded when
using the List-Owner field content to generate a message to the list
owner, and some even decode the 2047 encoding for display.  It is
true that for transport, there is no decoding, but that's axiomatic as
2047 is clearly intended for display purposes and not for processing
during transport.

Surely you're not suggesting that correct use of the List-Owner etc. header
fields to generate messages to the list owner etc. would be to use the raw
URL %-encoded text in the headers?  It seems that you're implying that a
To header generated from a mailto URL doesn't contain a mailbox even if it
matches the mailbox syntax and although a To header generated from any other
mechanism may contain a mailbox -- that doesn't sound right either. [as an
aside, technically the mailto URL syntax in RFC 2368 should probably specify
address rather than mailbox for compatibility with the To header syntax
unless there is some particular reason to exclude named groups]

> And as far as I
can tell, you can't have anything in a URL in a header field that a 2047 parser would recognize as a phrase or a comment.

URLs can contain parentheses (which is why there's a problem with the
RFC 2557 ABNF and CFWS).  A parser based on header syntax (revised in the
case of 2557) correctly identifies the URL as a URL and not a comment.
Examples have been given in earlier messages in this thread; a simplistic
matching of header field text using regular expressions might incorrectly
match a "comment" where there is none.



<Prev in Thread] Current Thread [Next in Thread>