ietf-822
[Top] [All Lists]

Re: quoted-pair in dcontent / Space after colon (Was: New 2822upd-04 - obs-NO-WS-CTL)

2008-01-24 04:48:30

With reference to:
  http://www.imc.org/ietf-822/mail-archive/msg06171.html

I was asked to comment. I've reviewed the ensuing thread, but am not fully aware of all prior discussion.


Pete Resnick wrote:
[On quoted-pair in dcontent...]

So, there are two forms to this request:

1. Remove quoted-pair entirely from dcontent in the generate syntax (meaning "[", "]", and "\" may never appear in dcontent). 2. Only allow the quoted-pairs "\[", "\]", and "\\" in dcontent in the generate syntax.

My personal opinion: #2 makes me queasy and I will argue tooth and nail against it. If people are heavily in favor of #1, I won't raise a stink,

The coder in me would prefer (1) that escaping be applied consistently *everywhere* in a message header, or (2) applied in as few different places as possible.

Since (1) is a long gone option [*], I'd favour #1 in the absence of any compelling reason to retain the escape chars in domains or message ids. I've scanned the thread forward from this message and in a fair amount of discussion have not seem any reason to keep these escapes. If not applied consistently per option (1), escaping in message ids seems like a particularly poor option, complicating as it does the very notion of identity comparison.

cf.
  http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#addrspec
  http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#ident

I agree with other comments that limiting to escapes to \[, \\, \], or simply allowing \ as a non-escape character are not desirable options. The former created yet another special case, and the I think latter has the potential for great nasty surprises - the use of \ as an escape in this context is, I think, just too deeply ingrained.

[*] Question for the reader: Is this still an implementation choice? I parse headers by first running an unescaping pass over the entire header, then parsing the resulting tokenized stream, I know I'll accept some headers that are strictly incorrect, but do I end up mis-interpreting or rejecting any valid headers? I'd like the answer to be No.


[On space after the ":"...]
My personal feeling on this is again it is not necessary, and that a gateway should be dealing with this anyway. But if people want text, I would be OK with a non-normative note in either 2.2 or 3.6. (Anything with a SHOULD I will make a stink over.) As editor, I'd want specific text agreed to and instructions on where to put it.

I agree that it's not necessary, but non-normative text is OK.

Reading this thread, it seems to me that this is a news/mail gateway issue and not really applicable 'within the framework of "electronic mail" messages' (cf. abstract), and as such the information might better belong in a separate informative document about implementing mail/news gateways, which could do more justice to a range of issues in this area.

cf.
  http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#fields
  http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#fielddefs

#g

--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

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