Re: Printing Error

[Brian Stafford <brian stafford uklinux net>]

On Fri, 14 December 19:51 Albrecht Dreß wrote:
> Am 14.12.01 09:07:47 schrieb(en) Olaf Frączyk:

>>> Also, is it correct that In-Reply-To: headers are RFC-2047 encoded? It
>>> might be useful to NOT encode the Message-ID contained for compatibility
>>> with non-MIME clients (and it may eben be mandatory to leave these
>>> In-Reply-To: unencoded, I didn't check RFC-2822 and RFC-2047/2049).
>> 
>> Sorry, don't know.
> 
> Ask Brian, our RFC guru ;-))

A guru replies ... ;)

A message-id is just an opaque token which is supposed to be globally unique, 
i.e. no two messages may have the same message-id.  One method of achieving 
this is to encode the time, a random number and a domain name.  RFC 2822 
constrains the structure of a message id but that is not really important for 
this discussion.  The angle brackets in the message id header are not part of 
a message id, they are just delimiters.  Since message-ids are opaque, they 
can only be copied and compared for identity.  A UA may not assume that 
message ids have structure or attempt to infer any meaning from the perceived 
structure.

The In-Reply-To: header contains a list of message-ids each contained within 
angle brackets.  Because the message id is opaque and its syntax is defined in 
RFC 2822, they cannot be considered to be RFC 2047 encoded.  Put another way, 
if an MUA out there is encoding message-ids with base64, quoted-printable, 
hex, whatever before inserting them in an In-Reply-To: header it is broken - 
period.  A message-id should be copied verbatim from the Message-Id: header of 
the referenced message.

Brian