rfc2047-decode-region

rfc2047-decode-region

[Eli Zaretskii]

This function accepts an optional ADDRESS-MIME argument, which is
described in the doc string thusly:

  If ADDRESS-MIME is non-nil, strip backslashes which precede characters
  other than `"' and `\' in quoted strings.

This gives absolutely no information about when to use this option and
why.  The emacs-mime manual doesn't even mention this argument.

Would people who are knowledgeable about this please tell what this
argument is all about?  Bonus points for fixing the docs as well ;-)

TIA

rfc2047-decode-region

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > This function accepts an optional ADDRESS-MIME argument, which is
 > described in the doc string thusly:
 > 
 >   If ADDRESS-MIME is non-nil, strip backslashes which precede characters
 >   other than `"' and `\' in quoted strings.
 > 
 > This gives absolutely no information about when to use this option and
 > why.

It's all in RFC 5322.  Doesn't everybody know that by heart? ;-)

 > The emacs-mime manual doesn't even mention this argument.

A "quoted string" in RFC 5322 is a string of printing ASCII
characters, excluding the backslash and the double quote, plus SPC,
TAB, and CRLF pairs enclosed in double quotes.  The backslash is a
no-op (ie, treated as not present) in such a quoted string except when
followed immediately by another backslash or a double quote.  The CRLF
is also a no-op (ie, used for folding).

Quoted strings are treated as "atoms", which are mostly of interest in
address parsing, thus the name, I guess.  MIME doesn't have anything
to do with it AFAICS; this definition is from the RFC 822 family.
Probably a better name would be "canonicalize-quoted-strings", since
it's not actually decoding them (that would involve translating
quoted-pairs of \\ and \" to \ and " respectively, and stripping out
CRLF pairs).

I think this behavior is actually broken, since rfc2047-encode-region
cannot know if any given string has been treated with ADDRESS-MIME
(and so the \\ and \" pairs should not be quoted to \\\\ and \\\"), or
not (in which ase they should be so quoted).  It probably doesn't
matter, though: uless somebody wants to deliberately screw you up
those pairs are very unlikely to occur in a raw string.

I would assume that this argument should be non-nil when decoding a
header field which is parsed into atoms, such as To or From.  Possibly
this would apply to Message-ID and References as well (in messages
conforming to RFC 5322 and maybe 2822, but in 822 References and
In-Reply-To were just unstructured text).

Re: rfc2047-decode-region

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 31 Dec 2011 21:48:44 +0900
> 
> Eli Zaretskii writes:
>  > This function accepts an optional ADDRESS-MIME argument, which is
>  > described in the doc string thusly:
>  > 
>  >   If ADDRESS-MIME is non-nil, strip backslashes which precede characters
>  >   other than `"' and `\' in quoted strings.
>  > 
>  > This gives absolutely no information about when to use this option and
>  > why.
> 
> It's all in RFC 5322.  Doesn't everybody know that by heart? ;-)

I didn't find a place that would explain how to compute 5322 from
2047.

> I would assume that this argument should be non-nil when decoding a
> header field which is parsed into atoms, such as To or From.  Possibly
> this would apply to Message-ID and References as well (in messages
> conforming to RFC 5322 and maybe 2822, but in 822 References and
> In-Reply-To were just unstructured text).

Thanks.  I needed it to decode a region of the "rmail view buffer",
where we display a single message, which includes all the displayed
headers, including From, To, CC, Subject, etc.  So from your
explanations I understand that the ADDRESS-MIME argument can stay nil
in that case, correct?

Re: rfc2047-decode-region

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > It's all in RFC 5322.  Doesn't everybody know that by heart? ;-)
 > 
 > I didn't find a place that would explain how to compute 5322 from
 > 2047.

I didn't either; that's why you need to know the RFC by heart.  Seems
a reasonable requirement for participation in a project which chooses
its infrastructure based on email controllability! :-)

 > Thanks.  I needed it to decode a region of the "rmail view buffer",
 > where we display a single message, which includes all the displayed
 > headers, including From, To, CC, Subject, etc.  So from your
 > explanations I understand that the ADDRESS-MIME argument can stay nil
 > in that case, correct?

Yes, if I were you I'd set it to nil.  Setting it to t makes some
*extremely* rare addresses (eg <"an\ RFC\-legit\ address"@gnu.org>,
and that is *not* a joke, it's the kind of example that ADDRESS-MIME
is intended for) look nicer.  But it probably would do really
confusing things to program strings in unstructured fields (eg, Lisp
regexps in the Subject field), and I think those are much more likely
than mailboxes whose names contain special characters.

Re: rfc2047-decode-region

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 02 Jan 2012 22:18:12 +0900
> 
> Eli Zaretskii writes:
> 
>  > > It's all in RFC 5322.  Doesn't everybody know that by heart? ;-)
>  > 
>  > I didn't find a place that would explain how to compute 5322 from
>  > 2047.
> 
> I didn't either; that's why you need to know the RFC by heart.  Seems
> a reasonable requirement for participation in a project which chooses
> its infrastructure based on email controllability! :-)

Well, I didn't really want to understand email.  I just wanted to fix
the display of some RFC 2047 encoded headers in Rmail, when the
message is not a MIME message.

>  > Thanks.  I needed it to decode a region of the "rmail view buffer",
>  > where we display a single message, which includes all the displayed
>  > headers, including From, To, CC, Subject, etc.  So from your
>  > explanations I understand that the ADDRESS-MIME argument can stay nil
>  > in that case, correct?
> 
> Yes, if I were you I'd set it to nil.

Thanks.  That's what I did in the first place, but I was unsure
whether it was TRT.