Subject: Re: draft-resnick-2822upd-02 and Netnews
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Date: Wed, 29 Aug 2007 11:33:38 GMT
List-Id: <ietf-822.imc.org>

In <[email-masked]> SM <[email-masked]> writes:

>Hi Charles,
>At 07:16 28-08-2007, Charles Lindsey wrote:
>>An RFC2822 parser that will not accept SP after the ':' will already be
>>non-compliant, and will still be non-compliant even if absence of that SP
>>is relegated to the obs-syntax. Moreover, since 99.999% of emails
>>currently sent already include that SP, such a parser would be totally
>>useless in the current email environment - so I think we can safely assume
>>that no such parser exists.

>We don't know the current email environment.  Each of us sees a 
>subset of it.  Put together, we get a better picture of it but we 
>still don't have the whole picture.  I, for one, would not assume 
>that no such parser exists.

But if it _does_ exist, then it will be incapable of reading 99.999% of
emails as currently sent, so I doubt anybody would be using it. And for
sure it would already be non-compliant, so I do not think we need be
concerned with it.

>>An existing RFC2822 agent that currently _generates_ headers without that
>>SP (I am not aware of any) would then become non-compliant, but the
>>messages it generated would still be accepted by all current and future
>>2822-bis-compliant agents.

>I thought that the aim of this update to RFC 2822 was not to make 
>existing implementations non-compliant.

No harm arises from making an existing implementation technically
non-compliant so long as all existing and future implementations are
REQUIRED to interoperate with it (as would be the case here).

The only thing such an implementation would not do is to interoperate with
Netnews.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5085
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-resnick-2822upd-02 and Netnews
Date: Wed, 29 Aug 2007 11:46:02 GMT
Lines: 29
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>Charles Lindsey writes:
>> An existing RFC2822 agent that currently _generates_ headers without 
>> that SP (I am not aware of any)

>I am aware of one that uses/used Tab.

Yes, some current Netnews software would accept WSP there, though some
would only recognize SP. For that reason, the USEFOR document requires SP
(possibly followed by further WSP/FWS/CFWS as appropriate).

However, it would still be an improvement in interoperability if 2822-bis
were to require at least WSP. But again, as I have just said elsewhere in
this thread, even if the implementation you mention were rendered
technically non-compliant by the change, it would still interoperate
correctly with all compliant email agents - just not with some Netnews
ones.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Tue, 28 Aug 2007 16:05:45 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Sender: [email-masked]

Barry Leiba wrote:
> [email-masked] said the following:
>> in any case, I'm seeing no support from anyone else for your proposals 
>> here,
>> so I think it is time to draw this discussion to a close.
> 
> To avoid the question of the meaning of silence, I'll be un-silent:
> Absolutely.  No support.  Close discussion.  S'il vous plait.

+1.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 28 Aug 2007 15:49:54 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Sender: [email-masked]

[email-masked] said the following:
> in any case, I'm seeing no support from anyone else for your proposals here,
> so I think it is time to draw this discussion to a close.

To avoid the question of the meaning of silence, I'll be un-silent:
Absolutely.  No support.  Close discussion.  S'il vous plait.

Barry

Date: Tue, 28 Aug 2007 12:41:46 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: draft-resnick-2822upd-02 and Netnews
Sender: [email-masked]

Hi Charles,
At 07:16 28-08-2007, Charles Lindsey wrote:
>An RFC2822 parser that will not accept SP after the ':' will already be
>non-compliant, and will still be non-compliant even if absence of that SP
>is relegated to the obs-syntax. Moreover, since 99.999% of emails
>currently sent already include that SP, such a parser would be totally
>useless in the current email environment - so I think we can safely assume
>that no such parser exists.

We don't know the current email environment.  Each of us sees a 
subset of it.  Put together, we get a better picture of it but we 
still don't have the whole picture.  I, for one, would not assume 
that no such parser exists.

>An existing RFC2822 agent that currently _generates_ headers without that
>SP (I am not aware of any) would then become non-compliant, but the
>messages it generated would still be accepted by all current and future
>2822-bis-compliant agents.

I thought that the aim of this update to RFC 2822 was not to make 
existing implementations non-compliant.

Regards,
-sm  

Date: Tue, 28 Aug 2007 20:26:14 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-resnick-2822upd-02 and Netnews
Cc: Charles Lindsey <[email-masked]>
Sender: [email-masked]

Charles Lindsey writes:
> An existing RFC2822 agent that currently _generates_ headers without 
> that SP (I am not aware of any)

I am aware of one that uses/used Tab.

Arnt

From: [email-masked]
Cc: [email-masked]
Date: Tue, 28 Aug 2007 10:44:47 -0700 (PDT)
Subject: Re: Comments on draft-resnick-2822upd-02.txt
To: Charles Lindsey <[email-masked]>
Sender: [email-masked]

> In <[email-masked]> [email-masked] writes:

> >> >If this really is worth addressing (and I'm 99.99% convinced it is not), the
> >> >way to do it is to tighten down the rules, not loosen them. For example, you
> >> >could say something like "the 78 character limit SHOULD be observed when
> >> >initially constructing messages but exceeding 78 characters SHOULD NOT be taken
> >> >as justification for modifying messages in transit".

> >> Yes, that would address my problem. In fact, it was one of the
> >> possibilities I suggested, but Pete was unconvinced :-(.

> >> Generally speaking, there should be a SHOULD NOT for changing _anything_
> >> during transit, except for Trace headers, changes of CTE (if you are
> >> unfortunate enough to encounter a non-8BITMIME system), or other such
> >> things explicitly allowed. Far better to let the end points deal with
> >> odd things that intermediate hops find odd.

> >Well, let's see. A _very_ incomplete list of legitimate things people do to
> >messages in transit would have to include:

> Sure, but I was not suggesting that as a change to be incorporated in that
> form at this time, but as a principle that we should move towards as and
> when opportunity arises.

> >(1) MIME conversions - upgrading as well as downgrading
> >(2) Format conversions and transcoding (we have formally defined
> >    specifications for this)
> >(3) Signature addition, removal, and verification. (DKIM would fit in here.)
> >(4) Encryption, decryption, and reencryption
> >(5) Gateways to and from other message formats, arguably including netnews
> >(6) Various sorts of processing related to mailing lists. (IMO some of what's
> >    done is legiti, some isn't, but attempts to pin down the rules for this
> >    have beenn _spectacularly_ unsuccessful.)
> >(7) Spam and virus filtering, including but not limited to labelling,
> >    part removal, and viral payload excision.

> Most of those affect only Trace headers (DKIM signatures are Trace
> headers),

Excuse me? It's exactly the opposite: Out of all of these the only one that
doesn't commonly involve message body modification is (2), and in that case
only if you're talking specifically about DKIM.

> or they are specifically allowed as part of related protocols.

Exactly the opposite is again the case: In spite of the fact that all of these
activities (and many more besides) have extremely compelling use cases, and in
one case (MIME downgrading) is for all intents and purposes required for useful
standards compliance, almost none of them are actually defined in some sort of
specification. And when such things have been defined (as is the case for
format conversions), the amount of pushback has been huge.

> Downgrading is fine (e.g. when passing to Non-8BITMIME systems); upgrading
> is undesirable except maybe at the agent that does final delivery (it
> breaks some signature algorithms). Likewise filtering is for final
> delivery agents, and not at other points during transit. Gateways (that
> inlcudes list expanders and other forms of forwarding) have of course to
> provide whatever the ongoing medium requires, and maybe that involves
> adding extra (trace-like) headers, but not removal or alteration of
> anything that can possibly be avoided.

Sigh. This is precisely the sort of thinking that has led to the present ugly
situation. Someone like you, apparently secure in the knowledge that you
understand everything there is to know about what people are trying to
accomplish and what the constraints they are operating under are, starts
throwing around a bunch of assessments of the form "this should be done this
way" or "this only makes sense in this situation" or "this has to be done at
this stage of processing". The problem is quite simply that you simply do not
have sufficient perspective to make such blanket statements.

And BTW, neither do I. My experiecne isn't necessarily more extensive and
certainly not better, it's just different.

I have neither the time nor the inclination to refute all of your assertions
here, so let me just pick the one that I actually regard has having the weakest
use-case of the lot: MIME upgrading. Email environments exist where essentially
all of the data being dealt with audio or video material. If the amount of data
is very large - and it often is - the 33% overhead of our most efficient
standard encoding is quite simply unacceptable in terms of the burden it places
on storage, transmission and encode/decode overhead. In such cases the approach
that may make the most sense is to upgrade to binary MIME as soon as possible
and keep things in that form as much as possible. (There are other, trickier
appproaches, but the ones with comparable effciency typically involve even more
extensive modifications to message content.)

in any case, I'm seeing no support from anyone else for your proposals here,
so I think it is time to draw this discussion to a close.

				Ned

To: [email-masked]
Xref: clerew local.mime:5077
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Date: Tue, 28 Aug 2007 13:45:25 GMT
Lines: 57
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> >If this really is worth addressing (and I'm 99.99% convinced it is not), the
>> >way to do it is to tighten down the rules, not loosen them. For example, you
>> >could say something like "the 78 character limit SHOULD be observed when
>> >initially constructing messages but exceeding 78 characters SHOULD NOT be taken
>> >as justification for modifying messages in transit".

>> Yes, that would address my problem. In fact, it was one of the
>> possibilities I suggested, but Pete was unconvinced :-(.

>> Generally speaking, there should be a SHOULD NOT for changing _anything_
>> during transit, except for Trace headers, changes of CTE (if you are
>> unfortunate enough to encounter a non-8BITMIME system), or other such
>> things explicitly allowed. Far better to let the end points deal with
>> odd things that intermediate hops find odd.

>Well, let's see. A _very_ incomplete list of legitimate things people do to
>messages in transit would have to include:

Sure, but I was not suggesting that as a change to be incorporated in that
form at this time, but as a principle that we should move towards as and
when opportunity arises.

>(1) MIME conversions - upgrading as well as downgrading
>(2) Format conversions and transcoding (we have formally defined
>    specifications for this)
>(3) Signature addition, removal, and verification. (DKIM would fit in here.)
>(4) Encryption, decryption, and reencryption
>(5) Gateways to and from other message formats, arguably including netnews
>(6) Various sorts of processing related to mailing lists. (IMO some of what's
>    done is legiti, some isn't, but attempts to pin down the rules for this
>    have beenn _spectacularly_ unsuccessful.)
>(7) Spam and virus filtering, including but not limited to labelling,
>    part removal, and viral payload excision.

Most of those affect only Trace headers (DKIM signatures are Trace
headers), or they are specifically allowed as part of related protocols.
Downgrading is fine (e.g. when passing to Non-8BITMIME systems); upgrading
is undesirable except maybe at the agent that does final delivery (it
breaks some signature algorithms). Likewise filtering is for final
delivery agents, and not at other points during transit. Gateways (that
inlcudes list expanders and other forms of forwarding) have of course to
provide whatever the ongoing medium requires, and maybe that involves
adding extra (trace-like) headers, but not removal or alteration of
anything that can possibly be avoided.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5078
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-resnick-2822upd-02 and Netnews
Date: Tue, 28 Aug 2007 14:16:58 GMT
Lines: 88
Sender: [email-masked]

In <[email-masked]> Dave Crocker <[email-masked]> writes:

>I believe what follows is largely or completely compatible with Pete's and 
>Ned's comments:

>Pete Resnick wrote:
>>> 2. SP after the ':' in headers
>>> ------------------------------
>>>
>>> That is REQUIRED in draft-ietf-usefor-usefor-12, and it is REQUIRED in 
>>> the new NNTP standard RFC 3977. Since every known MUA already 
>>> generates headers that way.......
>> 
>This really underscores the difference between making changes that "fix" 
>RFC2822, versus adding the (new) the goal of compatibility with other 
>messaging standards.

>The former is required for the current exercise.  But why is the latter?

>I mean, do we really want to go through the exercise of testing every single 
>RFC2822 parser, to make sure that we will not be breaking it (unnecessarily)?

An RFC2822 parser that will not accept SP after the ':' will already be
non-compliant, and will still be non-compliant even if absence of that SP
is relegated to the obs-syntax. Moreover, since 99.999% of emails
currently sent already include that SP, such a parser would be totally
useless in the current email environment - so I think we can safely assume
that no such parser exists.

An existing RFC2822 agent that currently _generates_ headers without that
SP (I am not aware of any) would then become non-compliant, but the
messages it generated would still be accepted by all current and future
2822-bis-compliant agents.

>There is no technical reason for requiring any white space here, since the 
>colon provides the necessary syntactic marker.  So requiring a space is either 
>a compatibility requirement for "interoperating" with other messaging 
>standards or it is a human factors usability requirement.  As much as the 
>latter might be appealing, I suspect we don't want to go down that path.

Exactly. The ONLY reason for REQUIRING that SP is for interoperability
with other messaging standards.

>This is the sort of specification detail that would have made quite a lot of 
>sense when we began writing messaging specs, but does not warrant the risk of 
>side-effects (to quote Pete) at the present stage of deployment.

What side effects? I have just demonstrated that no such side effect can
occur within any 2822- or 2822-bis-compliant agent.

>>> There is one slight consequence that you should then forbid header 
>>> lines with only whitespace after the header-name (because trailing 
>>> whitespace has a habit of getting lost).
>> 
>> And this gets us into a "changes with potential side-effects" problem 
>> that worries me.

Yes, I am not suggesting you go so far as to make that change (though a
SHOULD NOT do it might help). That still leaves a slight interoperability
problem, but one that would only show up only in very rare and improbable
circumstances.

>Indeed. Absent a clear and substantial demonstrating of operational problems, 
>we should not be making any changes to the specification.  Doing things that 
>appear to clean up the spec or otherwise make it better, absence a compelling 
>demonstration of need, is inviting problems.  Let's not do that.

The clear and substantial interoperability problem with Netnews has
already been demonstrated. It WOULD cause emails without that SP that were
gatewayed or cross-posted to Netnews (both of which are common practice)
to get lost/garbled/whatever. The only reason this does not pose a problem
at present is that emails (99.9999% of them) already insert that SP.

So all I am asking for is for that loophole to be closed. And the cost of
closing it within the email environment appears to be zero (and nobody has
demonstrated otherwise).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Mon, 27 Aug 2007 06:55:29 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: draft-resnick-2822upd-02 and Netnews
Sender: [email-masked]

Tony Finch wrote:
> On Sun, 26 Aug 2007, Dave Crocker wrote:
>> This really underscores the difference between making changes that "fix"
>> RFC2822, versus adding the (new) the goal of compatibility with other
>> messaging standards.
>>
>> The former is required for the current exercise.  But why is the latter?
> 
> Rather than impeding the 822 update, it would probably be more useful to
> write a document which tersely describes compatibility problems between
> 822 and usefor and how to generate messages that stay within the common
> subset.

Yup.

It would have been great to have the similar messaging environments use the 
same format standards, but that didn't happen.

The fact that they remain similar does not change the fact that this is really 
a gatewaying task that needs its own gateway mapping specification, just as 
was done for x.400.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 27 Aug 2007 11:21:22 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: draft-resnick-2822upd-02 and Netnews
Sender: [email-masked]

On Sun, 26 Aug 2007, Dave Crocker wrote:
>
> This really underscores the difference between making changes that "fix"
> RFC2822, versus adding the (new) the goal of compatibility with other
> messaging standards.
>
> The former is required for the current exercise.  But why is the latter?

Rather than impeding the 822 update, it would probably be more useful to
write a document which tersely describes compatibility problems between
822 and usefor and how to generate messages that stay within the common
subset.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Sun, 26 Aug 2007 09:23:28 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: draft-resnick-2822upd-02 and Netnews
Sender: [email-masked]

I believe what follows is largely or completely compatible with Pete's and 
Ned's comments:

Pete Resnick wrote:
>> 2. SP after the ':' in headers
>> ------------------------------
>>
>> That is REQUIRED in draft-ietf-usefor-usefor-12, and it is REQUIRED in 
>> the new NNTP standard RFC 3977. Since every known MUA already 
>> generates headers that way
> 
> Please some support for this, including a review of the DRUMS archive. 
> If we're going to make this change, you do the research. I seem to 
> remember a discussion of this during DRUMS, and having the space 

This really underscores the difference between making changes that "fix" 
RFC2822, versus adding the (new) the goal of compatibility with other 
messaging standards.

The former is required for the current exercise.  But why is the latter?

I mean, do we really want to go through the exercise of testing every single 
RFC2822 parser, to make sure that we will not be breaking it (unnecessarily)?

There is no technical reason for requiring any white space here, since the 
colon provides the necessary syntactic marker.  So requiring a space is either 
a compatibility requirement for "interoperating" with other messaging 
standards or it is a human factors usability requirement.  As much as the 
latter might be appealing, I suspect we don't want to go down that path.

This is the sort of specification detail that would have made quite a lot of 
sense when we began writing messaging specs, but does not warrant the risk of 
side-effects (to quote Pete) at the present stage of deployment.

> optional was where we ended up. Can we check?

>> There is one slight consequence that you should then forbid header 
>> lines with only whitespace after the header-name (because trailing 
>> whitespace has a habit of getting lost).
> 
> And this gets us into a "changes with potential side-effects" problem 
> that worries me.

Indeed. Absent a clear and substantial demonstrating of operational problems, 
we should not be making any changes to the specification.  Doing things that 
appear to clean up the spec or otherwise make it better, absence a compelling 
demonstration of need, is inviting problems.  Let's not do that.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: [email-masked]
Cc: [email-masked]
Date: Sun, 26 Aug 2007 04:49:39 -0700 (PDT)
Subject: Re: Comments on draft-resnick-2822upd-02.txt
To: Charles Lindsey <[email-masked]>
Sender: [email-masked]

> In <[email-masked]> [email-masked] writes:

> >> >Again, this line of challenge to the current spec seems to be attempting a
> >> >review of previously-resolved issues, rather than claiming that there are
> >> >known problems with the resolution and documenting the need for change.

> >> This is exactly such an example. Implementors seems to have taken that
> >> SHOULD as an excuse to "improve" messages during transit (not allowed if
> >> you read the spec correctly) or to avoid enabling display of these things
> >> robustly when they do arrive (also not allowed by the spec).

> >And I'll once again point out that these implementors have quite simply read
> >something into the specification that just isn't there. You cannot
> >cure such misreadings by removing compliance language - if you do that
> >they will simply say "there's nothing in the specification that says I cannot
> >or should not do this".

> >If this really is worth addressing (and I'm 99.99% convinced it is not), the
> >way to do it is to tighten down the rules, not loosen them. For example, you
> >could say something like "the 78 character limit SHOULD be observed when
> >initially constructing messages but exceeding 78 characters SHOULD NOT be taken
> >as justification for modifying messages in transit".

> Yes, that would address my problem. In fact, it was one of the
> possibilities I suggested, but Pete was unconvinced :-(.

> Generally speaking, there should be a SHOULD NOT for changing _anything_
> during transit, except for Trace headers, changes of CTE (if you are
> unfortunate enough to encounter a non-8BITMIME system), or other such
> things explicitly allowed. Far better to let the end points deal with
> odd things that intermediate hops find odd.

Well, let's see. A _very_ incomplete list of legitimate things people do to
messages in transit would have to include:

(1) MIME conversions - upgrading as well as downgrading
(2) Format conversions and transcoding (we have formally defined
    specifications for this)
(3) Signature addition, removal, and verification. (DKIM would fit in here.)
(4) Encryption, decryption, and reencryption
(5) Gateways to and from other message formats, arguably including netnews
(6) Various sorts of processing related to mailing lists. (IMO some of what's
    done is legiti, some isn't, but attempts to pin down the rules for this
    have beenn _spectacularly_ unsuccessful.)
(7) Spam and virus filtering, including but not limited to labelling,
    part removal, and viral payload excision.

Given all these activities (most but not all of which are described in a bunch
of other specifications) trying to come up with language specific enough to
provide compliance guidelines seems rather futile, especially since the list of
what's acceptable and what's not changes constantly. And saying something
generic like "message content SHOULD NOT be changed unless you have to" seems
rather pointless, since everyone who does this invariably thinks whatever they
are doing is OK. And as I've pointed out previously, such language has no place
in the message format specification in any case - it belongs in the transport
documents since other transports may impose very different rules on messages
than SMTP does.

No, I'm afraid this entire area is pretty gray and where attempting to nail
down compliance is effectively an attempt to codify good judgement. It would be
nice if that were possible, but it just isn't.

				Ned

P.S. The painful reality is that the rule some like to promulgate that our
transport mechanisms should never mess with message content, is "more honored
in the breach". And we need to stop pretending this isn't the case.

To: [email-masked]
Xref: clerew local.mime:5072
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Date: Sat, 25 Aug 2007 20:43:48 GMT
Lines: 42
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> >Again, this line of challenge to the current spec seems to be attempting a
>> >review of previously-resolved issues, rather than claiming that there are
>> >known problems with the resolution and documenting the need for change.

>> This is exactly such an example. Implementors seems to have taken that
>> SHOULD as an excuse to "improve" messages during transit (not allowed if
>> you read the spec correctly) or to avoid enabling display of these things
>> robustly when they do arrive (also not allowed by the spec).

>And I'll once again point out that these implementors have quite simply read
>something into the specification that just isn't there. You cannot
>cure such misreadings by removing compliance language - if you do that
>they will simply say "there's nothing in the specification that says I cannot
>or should not do this".

>If this really is worth addressing (and I'm 99.99% convinced it is not), the
>way to do it is to tighten down the rules, not loosen them. For example, you
>could say something like "the 78 character limit SHOULD be observed when
>initially constructing messages but exceeding 78 characters SHOULD NOT be taken
>as justification for modifying messages in transit".

Yes, that would address my problem. In fact, it was one of the
possibilities I suggested, but Pete was unconvinced :-(.

Generally speaking, there should be a SHOULD NOT for changing _anything_
during transit, except for Trace headers, changes of CTE (if you are
unfortunate enough to encounter a non-8BITMIME system), or other such
things explicitly allowed. Far better to let the end points deal with
odd things that intermediate hops find odd.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked], [email-masked], [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: Last Call: draft-saintandre-jabberid (The Jabber-ID Header  Field) to Proposed Standard 
Date: Fri, 24 Aug 2007 09:54:02 -0700
Sender: [email-masked]

--Apple-Mail-9--786154778
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

FYI on this last call document relating to email header fields.   
Please note that some review on the Apps-review team list has already  
suggested this go to Experimental instead  (http://www1.ietf.org/mail- 
archive/web/apps-review/current/msg00062.html ).

Thanks,
Lisa

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: August 24, 2007 6:51:05 AM PDT
> To: IETF-Announce <[email-masked]>
> Subject: Last Call: draft-saintandre-jabberid (The Jabber-ID  
> Header  Field) to Proposed Standard
> Reply-To: [email-masked]
>
> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'The Jabber-ID Header Field '
>    <draft-saintandre-jabberid-05.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2007-09-21. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-saintandre-jabberid-05.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_id&dTag=14260&rfc_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-9--786154778
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">FYI on this last call document =
relating to email header fields.=A0 Please note that some review on the =
Apps-review team list has already suggested this go to Experimental =
instead=A0 (<A =
href=3D"http://www1.ietf.org/mail-archive/web/apps-review/current/msg00062=
.html">http://www1.ietf.org/mail-archive/web/apps-review/current/msg00062.=
html</A> ).<DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Thanks,</DIV><DIV>Lisa</DIV><=
DIV><BR><DIV>Begin forwarded message:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>From: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">The IESG &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</F=
ONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Date: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">August 24, 2007 6:51:05 AM =
PDT</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>To: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">IETF-Announce &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FON=
T></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>Last Call: draft-saintandre-jabberid =
(The Jabber-ID Header<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Field) to Proposed Standard<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></B></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><B>Reply-To: =
</B></FONT><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica"><A =
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
IESG has received a request from an individual submitter to =
consider<SPAN class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">the following document:</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">- 'The =
Jabber-ID Header Field '</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN =
class=3D"Apple-converted-space">=A0=A0 =
</SPAN>&lt;draft-saintandre-jabberid-05.txt&gt; as a Proposed =
Standard</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The IESG plans to make a decision in the next few =
weeks, and solicits</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">final comments on this =
action.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>Please send =
substantive comments to the</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A> mailing lists by =
2007-09-21. Exceptionally,<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">comments =
may be sent to <A href=3D"mailto:[email-masked]">[email-masked]</A> =
instead. In either case, please<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">retain =
the beginning of the Subject line to allow automated sorting.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The file =
can be obtained via</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://www.ietf.org/internet-drafts/draft-saintandre-jabberid-05.t=
xt">http://www.ietf.org/internet-drafts/draft-saintandre-jabberid-05.txt</=
A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">IESG =
discussion can be tracked via</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_=
id&dTag=3D14260&rfc_flag=3D0">https://datatracker.ietf.org/public/pidtrack=
er.cgi?command=3Dview_id&amp;dTag=3D14260&amp;rfc_flag=3D0</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked]</A></DIV><DI=
V style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</A></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-9--786154778--

From: [email-masked]
Cc: [email-masked]
Date: Tue, 21 Aug 2007 11:08:03 -0700 (PDT)
Subject: Re: Comments on draft-resnick-2822upd-02.txt
To: Charles Lindsey <[email-masked]>
Sender: [email-masked]

> In <[email-masked]> Dave Crocker <[email-masked]> writes:

> >[email-masked] wrote:

> >In other words, I thought that later stages in the standards process were for
> >fixing known errors, rather than opening up the entire set of design and
> >specification decisions.

> IMHO it is also for spotting cases where you have made the rules too
> strict,

Well, that may be your opinion, but I'm afraid the rules say otherwise: A
document moving to draft can remove features and functionality but cannot add
any. Removing a restriction is a form of adding functionality and is therefore
not allowed.

> and maybe some backing off might make life simpler for future
> implementors.

Or it can make it far more difficult. This part's a judgement call, and I'll
again repeat that you're a long way from having made a case for such a change.

> It is your last chance to do such a thing.

You keep saying this like repetion will make it true. This entire execise of
revising 821/822 would not have been possible if this were true. And even if
this time around is indeed the last time we'll ever be able to revise these
base specifications, writing short specifications that update some small thing
or other is possible at any point.

In other words, if at some future point things change so it becomes clear that
advising implemenentations to limit line lengths ts 78 characters is a bad
idea, this can be changed quite simply by pushing a one page revision through
the process.

> >> So, while I get your point and see some benefit to tracking the implementation
> >> status of obsolete features (and non-obsolete ones as well), I don't believe
> >> the benefits of doing so exceed the costs. If this is to be done it should be
> >> done in some other document or perhaps just a web page.

> >Indeed.  Tracking adoption and use is nice, but not the job of a protocol
> >spec.  For that matter, I do not have the sense that it has been done all that
> >much in the IETF, other than what is required to go to Draft.

> >>> Can we de-emphasise that SHOULD, and make it clear that this is a matter
> >>> of good practice (in the sense of BCP) rather than a normative feature?
> >>
> >> That would be a significant change in normative language from RFC 2822 and
> >> could easily be seen as requiring a reset to proposed  Moreover, if memory
> >> serves, this language went into RFC 2822 not because the WG wanted it but
> >> rather because the IESG insisted on it.

> >Again, this line of challenge to the current spec seems to be attempting a
> >review of previously-resolved issues, rather than claiming that there are
> >known problems with the resolution and documenting the need for change.

> This is exactly such an example. Implementors seems to have taken that
> SHOULD as an excuse to "improve" messages during transit (not allowed if
> you read the spec correctly) or to avoid enabling display of these things
> robustly when they do arrive (also not allowed by the spec).

And I'll once again point out that these implementors have quite simply read
something into the specification that just isn't there. You cannot
cure such misreadings by removing compliance language - if you do that
they will simply say "there's nothing in the specification that says I cannot
or should not do this".

If this really is worth addressing (and I'm 99.99% convinced it is not), the
way to do it is to tighten down the rules, not loosen them. For example, you
could say something like "the 78 character limit SHOULD be observed when
initially constructing messages but exceeding 78 characters SHOULD NOT be taken
as justification for modifying messages in transit".

				Ned

To: [email-masked]
Xref: clerew local.mime:5068
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Date: Mon, 20 Aug 2007 20:29:09 GMT
Lines: 49
Sender: [email-masked]

In <[email-masked]> Dave Crocker <[email-masked]> writes:

>[email-masked] wrote:

>In other words, I thought that later stages in the standards process were for 
>fixing known errors, rather than opening up the entire set of design and 
>specification decisions.

IMHO it is also for spotting cases where you have made the rules too
strict, and maybe some backing off might make life simpler for future
implementors. It is your last chance to do such a thing.

>> So, while I get your point and see some benefit to tracking the implementation
>> status of obsolete features (and non-obsolete ones as well), I don't believe
>> the benefits of doing so exceed the costs. If this is to be done it should be
>> done in some other document or perhaps just a web page. 

>Indeed.  Tracking adoption and use is nice, but not the job of a protocol 
>spec.  For that matter, I do not have the sense that it has been done all that 
>much in the IETF, other than what is required to go to Draft.

>>> Can we de-emphasise that SHOULD, and make it clear that this is a matter
>>> of good practice (in the sense of BCP) rather than a normative feature?
>> 
>> That would be a significant change in normative language from RFC 2822 and
>> could easily be seen as requiring a reset to proposed  Moreover, if memory
>> serves, this language went into RFC 2822 not because the WG wanted it but
>> rather because the IESG insisted on it.

>Again, this line of challenge to the current spec seems to be attempting a 
>review of previously-resolved issues, rather than claiming that there are 
>known problems with the resolution and documenting the need for change.

This is exactly such an example. Implementors seems to have taken that
SHOULD as an excuse to "improve" messages during transit (not allowed if
you read the spec correctly) or to avoid enabling display of these things
robustly when they do arrive (also not allowed by the spec).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Mon, 20 Aug 2007 10:39:47 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Sender: [email-masked]

Dave Crocker wrote:
> 
> In other words, I thought that later stages in the standards process
> were for fixing known errors, rather than opening up the entire set of
> design and specification decisions.

At this point in standardization, we should be fixing known errors and
removing things that were never (with emphasis on never) implemented.

	Tony Hansen
	[email-masked]

Date: Sun, 19 Aug 2007 11:59:18 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Sender: [email-masked]

[email-masked] wrote:
>> Moreover, does it make sense to distinguish between obs constructs that
>> were theoretically permitted by RFC822 but in practice never seen in the
>> wild, as opposed to those which actually saw significant usage at one
>> time? IOW what possibilities exist for the eventual removal of at least
>> some of the weirder obs constructs?
> 
> The grammar is always quite complex and confusing. Adding another splitting
> point would make it even more complex and confusing. Additionally, I really
> don't think we need yet another round of interminable arguing over whether or
> not some system that hasn't been seen or heard of in several decades did such
> and such or so and so.

Discussing whether "it makes sense to distinguish" seems like a discussion 
that is appropriate for an initial development effort.  And of course that did 
take place during the writing of what became rfc2822.

To question the decision at this stage of the standards process would seem to 
me to require demonstrating that the current form of rfc2822 has caused 
problems that outweigh the benefits, with respect to this issue.  I'm not 
aware of any such claims.

In other words, I thought that later stages in the standards process were for 
fixing known errors, rather than opening up the entire set of design and 
specification decisions.

> So, while I get your point and see some benefit to tracking the implementation
> status of obsolete features (and non-obsolete ones as well), I don't believe
> the benefits of doing so exceed the costs. If this is to be done it should be
> done in some other document or perhaps just a web page. 

Indeed.  Tracking adoption and use is nice, but not the job of a protocol 
spec.  For that matter, I do not have the sense that it has been done all that 
much in the IETF, other than what is required to go to Draft.

>> Can we de-emphasise that SHOULD, and make it clear that this is a matter
>> of good practice (in the sense of BCP) rather than a normative feature?
> 
> That would be a significant change in normative language from RFC 2822 and
> could easily be seen as requiring a reset to proposed  Moreover, if memory
> serves, this language went into RFC 2822 not because the WG wanted it but
> rather because the IESG insisted on it.

Again, this line of challenge to the current spec seems to be attempting a 
review of previously-resolved issues, rather than claiming that there are 
known problems with the resolution and documenting the need for change.

That ain't what this stage of standardization is for, right?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: [email-masked]
Xref: clerew local.mime:5063
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Date: Fri, 17 Aug 2007 17:15:25 GMT
Lines: 43
Sender: [email-masked]

In <[email-masked]> Alan Barrett <[email-masked]> writes:

>Perhaps it would make sense to strengthen the idea that "Re:" is a fixed
>string not to be translated into other languages (I see "AW:" more often
>than any other attempted translation), and that things like "Re: re:" or
>"Re^2:" or "Re: AW: Re:"  should be avoided.  I seem to recall that
>USEFOR came up with some reasonable wording for this, but I can't find
>it now.

The wording at one time in USEFOR was:

   Followup agents MAY remove strings that are known to be used
   erroneously as back-reference (such as "Re(2): ", "Re:", "RE: ", or
   "Sv: ") from the Subject-content when composing the subject of a
   followup, and add a correct back-reference in front of the result.

        NOTE: that would be "SHOULD remove instances" except that we
        cannot find a sufficiently robust and simple algorithm to do the
        necessary natural language processing.

   Followup agents MUST NOT use any other string except "Re: " as a back
   reference. Specifically, a translation of "Re: " into a local
   language or usage MUST NOT be used.

        NOTE: "Re" is an abbreviation for the Latin "In re", meaning "in
        the matter of", and not an abbreviation of "Reference" as is
        sometimes erroneously supposed.

That is not in the present syntactic and semantic drafts, but there is an
intention for a third BCP draft (working title USEAGE) and similar wording
(and much more) appears in the current USEAGE draft. But what will go in
the final USEAGE draft remains to be seen.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5066
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Date: Fri, 17 Aug 2007 23:03:48 GMT
Lines: 340
Sender: [email-masked]

In <p0625011dc2e94f8089a2@[74.134.5.163]> Pete Resnick <[email-masked]> writes:

>On 8/15/07 at 9:44 PM +0000, Charles Lindsey wrote:

>>That last sentence seems wrong/confusing, given that the document 
>>specifies everything in terms of US-ASCII, presumably with the 
>>intent that US-ASCII should be the normal means of interchange over 
>>the 'wire' between agents (in the absence of explicit agreement 
>>otherwise).

>You can have a protocol that sends messages over the wire in UCS-2 or 
>UCS-4 (or a file format that so stores them). So long as they use 
>only code points 1-127, they are legal 2822 messages. (Over the wire 
>in US-ASCII might imply septets instead of octets. We certainly don't 
>want that.)

Point taken.

>>  >   There are two limits that this specification places on the number of
>>  >   characters in a line.  Each line of characters MUST be no more than
>>  >   998 characters, and SHOULD be no more than 78 characters, excluding
>>  >   the CRLF.
>>
>>Can we de-emphasise that SHOULD, and make it clear that this is a 
>>matter of good practice (in the sense of BCP) rather than a 
>>normative feature?

>It's not just good practice. Some agents screw up the display of long 
>lines as to make them unreadable to the user, and that's an 
>interoperation problem....

Then such agents are clearly broken, because there are some situations
where long lines cannot be avoided (long URLs, for example - the
recommended method for splitting URLs seems to be seldom implemented, so
people tend not to risk using it).

>>  >   Each header field should be
>>  >   treated in its unfolded form for further syntactic and semantic
>>                                              ^^^^^^^^^
>>>    evaluation.
>>
>>'Semantic' yes, but why is that 'syntactic' there?

>OK, I see what you're asking. You're saying that if you want to 
>syntactically see whether something is an address, it may contain 
>folding (syntactically), so there's no need to unfold to do 
>"syntactic evaluation". I was thinking of, "You can't just randomly 
>choose some line in a message and see if it's syntactically a 
>legitimate field, because that line might be the result of a fold". 
>(*Shrug*) I can't get excited about making a change.

I think John has persuaded me that it should stay.

>>  >3.2.2.  Quoted characters
>>
>>We have already noted that no-fold-quote, and no-fold-literal can go.

>No-fold-quote is gone in message-id (though still accepted in the 
>obs- syntax). I am still not sure what to do about no-fold-literal.

>>But, as I have pointed out in a separate thread, you would remove a 
>>severe interoperability problem with Netnews if you removed it from 
>><dcontent> as well (allowing just a "\" to appear as a normal 
>>character).

>There are too many implementations that have a dcontent (and qcontent 
>and ccontent) parser that will not deal with free "\" in any such 
>construct. So the only thing we could do would be to abolish "\" 
>completely in dcontent. And this is a path that I think would be 
>terrible to start down. So, no, I don't think we can make this change.

I agree that free "\" would not work in qcontent and ccontent.

But if it were allowed in dcontent, then the only thing allowed that is
not allowed currently would be domain-literals of the form [..........\].

Apart from that, it is only the semantic meaning that would change. And
the semantic meaning is of no interest internally within Email. It should
only arise within the semantics attached to whatever new addressing or
routeing protocol might choose to use it, and any special significance of
"\" within such a protocol could be defined by that protocol. Any
such domain-literal seen within Email should be regarded as an opaque
passenger - not to be interpreted or tinkered with, but simply to be
passed to agents implementing the new protocol as and when needed.

But if you do not want to make such a change to dcontent for use in
addr-specs, then just make the change within no-fold-literal where, for
sure, it will never be required to be passed to any other such new
protocol.

>>  >   within the range -9959 through +9959.
>>
>>why not "within the range -2359 through +2359"?

>I invite you to write up the review of the DRUMS discussion on this, 
>provide text, and tell us why we should change it.

It seems that the archive at ftp://cs.utk.edu/pub/drums/mail-archive/ is
no longer accessible. In any case, there is no means to search through an
ftp archive. If is is available in html somewhere, then Google could be used
to find stuff in it.

>>  >   A liberal syntax
>>  >   for the domain portion of addr-spec is given here; it is left to
>>  >   other specifications (e.g., [RFC1034], [RFC1035], [RFC1123],
>>  >   [I-D.klensin-rfc2821bis]) to give more precise limitations on the
>>>    syntax.
>>
>>Can we strengthen that by saying that the 'liberal syntax' MUST be 
>>further restricted to conform to some published specification such 
>>as the ones you have listed (without precluding further such 
>>specifications in the future, of course)?

>Like Ned, I'm opposed to the MUST, but would this suffice (and get us 
>out of having to change the syntax for dcontent for message-id if we 
>do a similar thing there)?

>"Note: A liberal syntax for the domain portion is given here. 
>However, the domain portion of addr-spec contains addressing 
>information used in other protocols (e.g., [RFC1034], [RFC1035], 
>[RFC1123], [I-D.klensin-rfc2821bis]). It is therefore incumbent upon 
>implementations to conform to the syntax of addresses for the context 
>in which they are used."

Yes, that would indeed help. But I would still prefer to fix it
syntactically, at least within no-fold-literal.

>>...some people 'munge' their From: addresses in order to appear 
>>anonymous, or to confuse address harvesters. Whether that is a 
>>desirable practice or not is none of our business, but a normative 
>>interpretation of those words would seem to rule it out.
>>[...]
>>  >   In all cases, the "From:" field SHOULD NOT contain any mailbox that
>>>    does not belong to the author(s) of the message.  See also section
>>>    3.6.3 for more information on forming the destination addresses for a
>>  >   reply.

>Wanting to appear anonymous or confuse address harvesters seems 
>squarely in the category of "there may exist valid reasons in 
>particular circumstances when the particular behavior is acceptable 
>or even useful, but the full implications should be understood and 
>the case carefully weighed before implementing any behavior described 
>with this label." [RFC 2119] So, the normative language seems good as 
>well as the potential violation.

It is clearly impossible to stop people from doing this, both in Usenet
and also in highly visible mailing lists. Recognizing this, our main
concern in USEFOR was to discourage people from accidentally using an
address that might actually turn out to belong to someone else, and also
to reduce any possible load on the root DNS servers. So the SHOULD NOT you
quote above is fine for that as far as it goes.

My main concern was the earlier wording in 3.6.2 which can be (and has
been) interpreted as forbidding using a bogus address in From or Sender
(it would be stupid in Reply-To, of course). Whilst the practice should be
discouraged, of course, I think that bit needs to be reworded so make it
clear that it is not laying down a normative requirement.

Even just saying "The "From:" field normally specifies the author(s) of
the message ..." (and similarly for "Sender:") would suffice the clear up
any possible misunderstanding.

>>  >   "References:" field may be used to identify a "thread" of
>>                         ^^^^^^
>>                        is often

>Why?

Because it better describes the actual way that field is currently used,
and increases (slightly, but every bit counts) the incentive for people
to create that field correctly.

>>It would be useful to mention that when the References field gets 
>>too long it MAY be pruned (the minimum requirement being to retain 
>>the first and the last two entries - including the one just being 
>>added). I have known of cases where References fields grew to such a 
>>length (and MUAs in the followup chain had failed to introduce 
>>folding, or even removed folding already present) that the 998 limit 
>>was breached with disastrous consequences.

>I am loathe to put in pruning instructions at this point, and without 
>such instructions, I don't see what else to say.

The wording currently proposed for USEFOR is:

   If the resulting References header field would, after unfolding,
   exceed 998 characters in length (including its field name but not the
   final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
   Trimming means removing any number of message identifiers from its
   content, except that the first message identifier and the last two
   MUST NOT be removed.

I am not asking for wording that strong (though you can see that the
USEFOR WG takes the correct usage of References as a matter of highest
importance, because threading is universally regarded as an important and
desirable feature within Usenet). A MAY would be quite strong enough to
show that such pruning is _allowed_.

And in fact, the case I am aware of where a References chain got so long
that software actually choked on it was in a mailing list, and not in
Usenet, although the possibility can easily arise in both.

>>It would be useful to say here that two msg-ids can always be 
>>compared for equality by a simple octet-by-octet comparison (but, of 
>>course, one would first have to ensure that property was true).

>I also don't want to put threading instructions into this document, 
>which is the path the above starts down.

Sure, that needn't be said, even though it is the only situation where
such comparisons are routinely used in Email (actually, I believe there do
also exist email archives that can be indexed by msg-id).

>>  >   The "Received:" field contains a
>>  >   (possibly empty) list of tokens followed by a semicolon and a date-
>>>    time specification.  Each token must be a word, angle-addr, addr-
>>  >   spec, or a domain.
>>
>>Can be find a better word instead of "token" here? "Token" usually 
>>means some sort of keyword (e.g. as used in the MIME standards).

>I kinda like "token". "Lexeme" seems too syntactic. "Item" seems too generic.

But Ned likes "item". Anybody else want to play? There are probably other
words that people might like to suggest.

>>  >3.6.8.  Optional fields
>>>
>>  >   Fields may appear in messages that are otherwise unspecified in this
>>  >   document.  They MUST conform to the syntax of an optional-field.
>>>    This is a field name, made up of the printable US-ASCII characters
>>  >   except SP and colon, followed by a colon, followed by any text which
>>  >   conforms to unstructured.
>>
>>This is misleading, because it has to cover all new header fields 
>>introduced by extensions and these will be, in general, structured.

>That's not what that says. It says that it will conform to unstructured syntax.

Indeed, but most of the headers that have been defined (e.g. all of
Content-* from MIME) are structured, and software that tries to treat them
as "unstructured" (as 2822 claims them to be) can easily do the Wrong
Thing. So better to remove any possible excuse for doing that.

>>  >      Note: The "period" (or "full stop") character (".") in obs-phrase
>>
>>But this is not an "obsolete" construct. We discussed this around 12 
>>months ago, and the consensus then was that it ought to be renamed 
>>as an <extended-phrase>, and moved out of the Obsolete Syntax.

>There was no such consensus; you were the only one who ever suggested 
>it on this list. And I still see no reason to change it (as I stated 
>back then).

OK, I have reviewed the discussion, and there was less of it than I seemed
to remember. I suggested it. Bruce Lilly agreed. You disagreed.

But I still think that renaming it as "extended-phrase" would better
reflect the realities of the situation.

>>  >4.3.  Obsolete Date and Time
>>
>>This lot was particularly difficult to spot the differences.

>I'm not sure I understand why. I'd prefer to leave it as is. There 
>have been enough bugs in this section already that occurred by trying 
>to over-simplify the syntax.

>>  >   addition, local-part is allowed to contain quoted-string in addition
>>                          ^^                                  ^^^^^^^^^^^
>>                         was

>"Is" allowed in this syntax.

OK

>>  >   to just atom.  Finally, ....
>>     ^^^^^^^^^^^^
>>     in lieu of any of those period-separated atoms

>That's incorrect. You can mix atoms and quoted-strings.

Which is what I said. In the regular syntax you can have a list of
period-separated atoms (by virtue of the newly-invented dot-atom). So I
said that, in the obs-syntax, any of those atoms can, instead, be a
quoted-string.

But it is not a huge deal.

>>  >   Messages are delimited in this section between lines of "----".  The
>>>    "----" lines are not part of the message itself.
>>
>>That is indeed an excellent notation. The Bad News is that you have 
>>nowhere used it :-( .

>I'll try figure out how to do something useful in xml2rfc.

Please do.

>>Wouldn't it be better to show a Bcc: header for the "Undisclosed 
>>recipients" example?

>I don't understand what you mean.

Just more typical of the way the group syntax is used in practice. I have
often seen that "Undisclosed recipient" in a (deliberately emaciated)
Bcc:, but I have never seen it in a Cc:. Surely someone who wanted to do
that wold be using a Bcc: in the first place.

Again, not a huge deal.

>>  >   The above example is aesthetically displeasing, but perfectly legal.
>>
>>Though legal, you should point out that it contains things that are 
>>deprecated by 3.3 and by 3.4.1

>Nope. A.5 does not (or shouldn't unless I missed something) contain 
>anything not perfectly permissible in 3.3 and 3.4.1.

3.3 and 3.4.1 permit them, but also discourage/deprecate them.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5064
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Date: Fri, 17 Aug 2007 17:18:26 GMT
Lines: 50
Sender: [email-masked]

In <[email-masked]> SM <[email-masked]> writes:

>At 14:44 15-08-2007, Charles Lindsey wrote:
>> >2.1.1.  Line Length Limits
>> >
>> >   There are two limits that this specification places on the number of
>> >   characters in a line.  Each line of characters MUST be no more than
>> >   998 characters, and SHOULD be no more than 78 characters, excluding
>> >   the CRLF.
>>
>>Can we de-emphasise that SHOULD, and make it clear that this is a matter
>>of good practice (in the sense of BCP) rather than a normative feature?
>>Perhaps s/SHOULD/should/? Too many agents have used this as an excuse to
>>rewrite lines en route (maybe there should be a SHOULD NOT for that).

>I read that as more than a BCP.  Quoting a message from the 2822 era:

>   "The 78 character recommendation is due to limitations in many
>    implementations which display these messages which may truncate display
>    of more than 78 characters per line. Of course, even though these
>    limitations are put on messages, interpreters of messages would do well
>    to handle an arbitrarily large number of characters in a line, including
>    for display, for robustness' sake."

>>Where did that '78' come from? I am aware of lots of systems that do
>>horrid things such as you mention if there are 80 characters in a line,
>>but I am aware of none where problems arise with exactly 79. In other fora
>>where I have seen this discussed, the consensus was that exceeding '79'
>>was the signal for troubles to start.

>There are 80 characters per line on a text display.  There may be a 
>one character border on the left and right hand side.  That leaves 
>you with 78 characters.  Some (old) displays do not wrap a long 
>line.  Although it may sound obsolete in this day and age, some 
>messages may be sent directly to a printer which may have the same line limit.

I have never seen a text display with a one character border at the left,
though I have seen many with such a border at the right (and which causes
strange wrappings if you try to use it).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5065
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Date: Fri, 17 Aug 2007 20:44:04 GMT
Lines: 446
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> >1.  Introduction
>> >
>> >1.1.  Scope
>> >
>> >   This document specifies a syntax only for text messages.  In
>> >   particular, it makes no provision for the transmission of images,
>> >   audio, or other sorts of structured data in electronic mail messages.
>> >   There are several extensions published, such as the MIME document
>> >   series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
>> >   for the transmission of such data through electronic mail,........

>> No mention of RFC 2047, or of RFC 2231?

>RFC 2047 specifies a means to include non-ASCII text in email headers and has
>essentially nothing to do with the transmission of structured data through
>email. So why should it be mentioned in this context?

OK, if this paragraph is intended for Content-Type stuff in bodies. And
there is a mention of RFC 2047 later on in a more relevant context (but
then RFC 2231 should problem get a mention at that place).

>> >1.2.  Notational conventions
>> >
>> >1.2.3.  Structure of this document
>> >

>> Can we be clear about the _intent_ of this obs-syntax?

>> Is the intent to be able to read/display/print ancient messages which
>> people still have on file? In which case, please can we say that there is
>> no longer any expectation that obs messages can still be transmitted and
>> delivered (by RFC2821 or otherwise), and hence only MUAs (but not MTAs)
>> are REQUIRED to accept them.

>> Or, alternatively, is the intent that some ancient software still
>> generates messages using the obs-syntax, and hence MTAs MUST still accept
>> them? In which case, for how much longer?

>I see little if any justification for additional elaboration of the intent
>here. As far as I'm oncerned the intent covers both your "alternatives' and
>quite a few other things as well.

>More generally, the problem with trying to nail down intent is that once you do
>so the ability of the construct to meet other, as-yet-unplanned needs may be
>compromised. See below for an example of another possible use of the obs-
>syntax - helping with interop requirements - should we make our own lives
>harder down the road simply because this document didn't say that one
>intent of this was to make feature enumeration easier?

It's a question of the remote possibility that some future benefit of
keeping the obs-syntax in place will appear; versus the certainty that
implementors will for ever be REQUIRED to accept some things that are
notoriously difficult to parse (such as bare CR or LF or NULL) and which
will surely never be encountered. Keeping these things off the wire and
with no requirement for agents that take things off the wire to continue
to accept them would be a good start.

Being cautious in what changes you introduce at Draft Standard stage is a
fine thing, but it has to be set against the fact that this is your last
chance to remove things which have outlived their usefulness and would not
be missed. Beyond Draft Standard, the concrete in which these things are
set becomes so hard that it can NEVER be broken.

>> >2.  Lexical Analysis of Messages
>> >

>> >2.1.1.  Line Length Limits
>> >
>> >   There are two limits that this specification places on the number of
>> >   characters in a line.  Each line of characters MUST be no more than
>> >   998 characters, and SHOULD be no more than 78 characters, excluding
>> >   the CRLF.

>> Can we de-emphasise that SHOULD, and make it clear that this is a matter
>> of good practice (in the sense of BCP) rather than a normative feature?

...............

>Besides, I think a SHOULD is actually appropriate here. SHOULD means you should
>do it unless you have a really good reason not to.

>> Perhaps s/SHOULD/should/? Too many agents have used this as an excuse to
>> rewrite lines en route (maybe there should be a SHOULD NOT for that).

>If so, they are relying on a flagrant misreading of the document. Attempting to
>prevent such exercises is itself and exercise in futility - the best you can
>ever do is point out that the claim isn't supported by the actual language.

But people DO flagrantly misread documents, and have done so in this case.
So that SHOULD has caused actual harm. RFC 2119 itself admits that the
interpretation of MUST and SHOULD might well be different in BCP and other
informational documents, but this document is clearly intended to be
normative, except where it chooses to make it clear that it is only giving
advice.

>As for having a SHOULD NOT about agents altering messages in transit, IMO the
>place for that - assuming it makes sense to do - would be the SMTP
>specification, not here.

That would be a good thing to say in 2821bis. But it should apply equally
to ANY transport mechanism - old or new.

>> >   The more conservative 78 character recommendation is to accommodate
>> >   the many implementations of user interfaces that display these
>> >   messages which may truncate, or disastrously wrap, the display of
>> >   more than 78 characters per line, in spite of the fact that such
>> >   implementations are non-conformant to the intent of this
>> >   specification (and that of [I-D.klensin-rfc2821bis] if they actually

>> Where did that '78' come from? I am aware of lots of systems that do
>> horrid things such as you mention if there are 80 characters in a line,
>> but I am aware of none where problems arise with exactly 79. In other fora
>> where I have seen this discussed, the consensus was that exceeding '79'
>> was the signal for troubles to start.

>I've always felt that the 78 character limit was one byte lower than it really
>needed to be. But I a long way from convinced that now is the time to change
>this.

It's your last chance :-( . And existing systems that use 78 would still
be compliant, or at least as compliant as they were before.

>> >2.2.3.  Long Header Fields
>> >
>> >   ......  Each header field should be
>> >   treated in its unfolded form for further syntactic and semantic
>>                                              ^^^^^^^^^
>> >   evaluation.

>> 'Semantic' yes, but why is that 'syntactic' there?

>Don't you have to parse things like address fields in order to then perform
>semantic analysis? .........

Ah! you mean that you have

   To: <a-very-long-name-such-as-frederickickickick
        @example.com>

(which is ugly but allowed). So you have to unfold before you can
recognize that you have an <addr-spec>. Point taken.

>> >3.2.2.  Quoted characters
>> >
>> >
>> >      Note: The "\" character may appear in a message where it is not
>> >      part of a quoted-pair.  A "\" character that does not appear in a
>> >      quoted-pair is not semantically invisible.  The only places in
>> >      this specification where quoted-pair currently appears are
>> >      ccontent, qcontent, dcontent, no-fold-quote, and no-fold-literal.

>> .... But,
>> as I have pointed out in a separate thread, you would remove a severe
>> interoperability problem with Netnews if you removed it from <dcontent> as
>> well (allowing just a "\" to appear as a normal character).

>As I believe I stated in an earler response, I am opposed to removing it. It is
>simply not possible to know everything that's out there and just because we
>don't know about something is no excuse to break it.  I could live with moving
>it to the obsolete syntax but that's as far as I'll go.

Indeed, moving it to obs-syntax is all I am asking for (though allowing
"\" in <dtext> might be tricky - I shall respond to Pete's remarks on
that).

>> >3.2.3.  Folding white space and comments
>> >

>> Do you _really_ want to permit NO-WS-CTL in a <comment>?

>RFC 2822 did, so the question becomes one of do we want to change
>this away from what 2822 said?

>Like it or not, control characters have long been allowed in a lot of places
>where they really don't belong. I remain to be convinced that this one
>narrow case is worth worrying about.

It (and other similar cases) is a good candidate for the obs-syntax, then.
There may be a few cases where they may be meaningful in the protocol (so
it is up to 2821bis to make the final pronouncement), but this is not one
of them. We had a purge on them in USEFOR, notably in Message-ID where
characters that are not visible on the screen could provide a golden
opportunity for all sorts of scams.

>> <phrase>s, <unstructured>s and <comment>s are the places where RFC 2047
>> raises its ugly head. It is the most confusingly written RFC I have
>> encountered (and it could be considered as separate from the rest of
>> the MIME standards, since it can be used without the MIME-Version header).

>> For a truly outrageous suggestion, we might incorporate the whole of RFC
>> 2047 into here, cleaning it up in the process. No, that is too much to
>> propose at this juncture, but there are a couple of lesser things we might
>> do to help:

>> 1. Include <encoded-word> in the syntax at all the proper places (which
>> might at least encourage inventors of new extension headers to follow
>> suit). It would need a convincing explanation, of course.

>I am strongly opopsed to this. If RFC 2047 is confusing, the time to argue that
>is when it is revised. We cannot fix it's problems (assuming there actually are
>any to fix) by incorporating some subset of references to it in another
>document.

Yes, I didn't expect that one to fly ;-( .

>> 2. And if that is a step too far, we could still point out that sequences
>> of the form "=? ... ? ... ? ... ?=" have a special significance within RFC
>> 2047 (whether they exceed that 76 character limit or not), and that such
>> sequences SHOULD NOT be used within <phrase>s, <unstructured>s and
>> <comment>s unless that special significance is intended.

>An informational reference to RFC 2047 would be OK with me.

"Within 'comment's, 'phrase's and 'unstructured's, sequences of the form
"=? ...  ? ... ? ... ?=" have a special significance within RFC 2047 for
encoding characters outside the range of US-ASCII. Such sequences SHOULD
NOT therefore be used unless that special significance is intended."

3.2.6 might be a possible home for such a remark. Possibly as a Note.

>> >3.3.  Date and Time Specification

>> why not "within the range -2359 through +2359"?

>I have no objection to restricting the range, but whatever we do needs to agree
>with other specifications that deal in time zones. RFC 3339 appears to allow
>-2459 through +2459. 

That would be fine (apparently funny things can happen aroung the Date
Line). Though I didn't actually find anything about that in RFC 3339.

>> >3.4.1.  Addr-spec specification
>> >
>> >   .......  A liberal syntax
>> >   for the domain portion of addr-spec is given here; it is left to
>> >   other specifications (e.g., [RFC1034], [RFC1035], [RFC1123],
>> >   [I-D.klensin-rfc2821bis]) to give more precise limitations on the
>> >   syntax.

>> Can we strengthen that by saying that the 'liberal syntax' MUST be further
>> restricted to conform to some published specification such as the ones you
>> have listed (without precluding further such specifications in the future,
>> of course)?

>No, because that would usurp the perogative of other specifications to
>specify what conformances criteria apply to their additional restrictions.

>> I have already pointed out, in a separate thread, the severe
>> interoperability problems with Netnews of this definition of <dcontent>
>> (at least insofar as its use within <msg-id> is concerned).....

>And IMO you failed to achieve sufficient support to result in a specification
>change. As I said previously, I can live with making the use of quoted-pairs in
>dtext part of the obsolete syntax, but that's as far as I can see us going.

Yes, that would be the best way IMHO.

>The alternative approach I actually favor is one I have previously described:
>Add some text that says that domain literals in message ids should be generated
>using the most restrictive syntax and with well-defined semantics, i.e. an IPv4
>or IPv6 literal. To mind the bigger problem here is that someone will generate
>something like [foobar] here instead of putting in an actual global IPv4 or
>IPv6 address. If we encourage people to use domain literals with defined
>semantics we solve several problems at one go.

Sure, but that was the intent of my suggested "'liberal syntax' MUST be further
restricted to conform to some published specification" which you did not
like. But I see that Pete has suggested a possible text which achieves
much the same effect.

>> >3.6.  Field definitions

>> I have already pointed out, in a separate thread, the severe
>> interoperability problem that arises with Netnews if you do not require a
>> SP after the colon. Since every MUA I am aware of routinely inserts that
>> SP, I cannot see that anything would be lost by requiring it here.

>And as I commented previously, not everything that has an submissiion client in
>it is an MUA. There are quick and dirty submission clients embedded in all
>sorts of places - one of the advantages of SMTP is that you can code a quick
>and dirty client very easily - and leaving out every possible character is
>exactly the sort of things these gizmos do. Heck, they  even do it when they've
>actually got plenty of space to space - unnecessary optimization is RAMPANT in
>the embedded systems world.

But surely anybody writing a script to do a "dirty submission" is going to
write something like:

   sprintf(buffer, "Foo-Header: %s, %d, ...\n", stuff1, stuff2)

either in C, or in one of the many scripting languages (e.g. Perl) which
supports constructs like that, because that is the easiest way to generate
such things. And they will tend to put that SP in simply because that is
how they always expect to see headers. It would take a conscious
decision to be "different" for them to do otherwise.

>> >3.6.2.  Originator fields

>> >   The originator fields indicate the mailbox(es) of the source of the
>> >   message.  The "From:" field specifies the author(s) of the message,
>> >   that is, the mailbox(es) of the person(s) or system(s) responsible
>> >   for the writing of the message....

>> Are those sentences intended to be normative, BCP (or even deliberately
>> vague :-) ).

>Don't see any capitalized words there, do you? So I guess there are
>no compliance implications.

>> For example, some people 'munge' their From: addresses in order to appear
>> anonymous, or to confuse address harvesters. ...

>> The wording currently proposed by the USEFOR WG for this is:

>>    Contrary to [RFC2822], which implies that the mailbox or mailboxes in
>>    the From header field should be that of the poster or posters, a
>>    poster who does not, for whatever reason, wish to use his own mailbox
>>    MAY use any mailbox ending in the top level domain ".invalid"
>>    [RFC2606].

>> But if RFC2822 does not actually imply that, then we might have to think
>> again.

>And IMO it should not imply that. The last thing email needs at this point is
>more license to use invalid addresses.

No, you misread what I said. "If RFC does not actually imply that
munged_addresses_etc_are_disallowed" (and you seem to be saying that it
does not), then the USEFOR WG needs to review that wording which says
"Contrary to [RFC2822]...", because it would not be contrary.

But, since people seem to be reading if both ways, it needs to be
clarified.

>> >3.6.4.  Identification fields
>> >
>> >   The "Message-ID:" field contains a single unique message identifier.
>> >   The "References:" and "In-Reply-To:" field each contain one or more
>> >   unique message identifiers, optionally separated by CFWS.
>>                                 ^^^^^^^^^^

>> Interoperability with Netnews would be improved without that "optionally".

>Perhaps, but like it or not Netnews compatibility is not our primary goal here.

It is a very common practice to gateway message-lists into Netnews (you
can find this list on Usenet if you look for it). And it is also common
for people to both mail and post the same message/article. Therefore,
interoperability with Netnews is an important goal, especially where it
can be achieved with zero or minimal disruption to present practices.

Actually, the CFWS in the References header is one of the less urgent
problems. A "SHOULD include" it would be strong enough, given that USEFOR
felt able to say that its absence "SHOULD be accepted", so that eventually
the two will come into line.

>> >   The "References:" field will contain the contents of the parent's
>> >   "References:" field (if any) followed by the contents of the parent's
>> >   "Message-ID:" field (if any). ...

>> It would be useful to mention that when the References field gets too long
>> it MAY be pruned (the minimum requirement being to retain the first and
>> the last two entries - including the one just being added). I have known
>> of cases where References fields grew to such a length (and MUAs in the
>> followup chain had failed to introduce folding, or even removed folding
>> already present) that the 998 limit was breached with disastrous
>> consequences.

>Adding such a suggestion would be fine with me were it not for the context of
>this effort - every such change increases the likelihood of a problem getting
>to draft.

All it needs is a MAY. Given that lack of it has actually caused breakage
in the past, and certainly does no harm, it would seem wise to allow it.
USEFOR intends to allow (and even to encourage) it.

>> >3.6.5.  Informational fields
>> >

>> >   ....  When used in a reply, the field body MAY start with the
>> >   string "Re: " (from the Latin "res", in the matter of) followed by
>> >   the contents of the "Subject:" field body of the original message.

>> If we are going to discuss Latin Grammar, then please let us to so
>> correctly. "Res" is the nominative form of the fifth declension noun
>> meaning "thing", "matter", "issue", etc.  "Re" is an abbreviation of the
>> phrase "in re" meaning "in the matter of", and in which "re" is the
>> ablative form of the same noun (the preposition "in" is always followed by
>> an ablative in static cases such as this, though it takes the accusative
>> form - e.g. "in rem" - in dynamic cases where the meaning is "into").

>> so if, instead of
>>     the string "Re: " (from the Latin "res", in the matter of)
>> you write
>>     the string "Re: " (an abbreviation of the Latin "in re", meaning "in
>>     the matter of")
>> all will be correct.

>Yep, now that I think about it you're correct. This is a reasonable change.
>Alternately, the  whole thing about the Latin could be omitted.

I think it is needed because two many people imagine that it is an
abbreviation of "reference", and then try to use an abbreviation of an
equivelent word in their own language. And that definitely causes things
to break.

>> >Appendix A.  Example messages
>> >
>> >   Messages are delimited in this section between lines of "----".  The
>> >   "----" lines are not part of the message itself.

>> That is indeed an excellent notation. The Bad News is that you have
>> nowhere used it :-( .

>Yes, and so this sentence would best be removed.

I would prefer that the feature be used as intended.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Fri, 17 Aug 2007 09:54:03 +0200
From: Alan Barrett <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Sender: [email-masked]

On Thu, 16 Aug 2007, [email-masked] wrote:
> > so if, instead of
> >     the string "Re: " (from the Latin "res", in the matter of)
> > you write
> >     the string "Re: " (an abbreviation of the Latin "in re", meaning "in
> >     the matter of")
> > all will be correct.
> 
> Yep, now that I think about it you're correct. This is a reasonable change.
> Alternately, the  whole thing about the Latin could be omitted.

Perhaps it would make sense to strengthen the idea that "Re:" is a fixed
string not to be translated into other languages (I see "AW:" more often
than any other attempted translation), and that things like "Re: re:" or
"Re^2:" or "Re: AW: Re:"  should be avoided.  I seem to recall that
USEFOR came up with some reasonable wording for this, but I can't find
it now.

--apb (Alan Barrett)

Date: Thu, 16 Aug 2007 23:13:26 -0500
To: "Charles Lindsey" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Cc: [email-masked]
Sender: [email-masked]

I just got through reading Ned's response. Glad I don't have to 
polish my own responses, as his are almost entirely spot-on. To 
things that Ned didn't address (or to which I have additions):

On 8/15/07 at 9:44 PM +0000, Charles Lindsey wrote:

>  >   messages.  This specification is a revision Request For Comments
>                                                ^
>                                                of

Got it.

>That last sentence seems wrong/confusing, given that the document 
>specifies everything in terms of US-ASCII, presumably with the 
>intent that US-ASCII should be the normal means of interchange over 
>the 'wire' between agents (in the absence of explicit agreement 
>otherwise).

You can have a protocol that sends messages over the wire in UCS-2 or 
UCS-4 (or a file format that so stores them). So long as they use 
only code points 1-127, they are legal 2822 messages. (Over the wire 
in US-ASCII might imply septets instead of octets. We certainly don't 
want that.)

>  >   There are two limits that this specification places on the number of
>  >   characters in a line.  Each line of characters MUST be no more than
>  >   998 characters, and SHOULD be no more than 78 characters, excluding
>  >   the CRLF.
>
>Can we de-emphasise that SHOULD, and make it clear that this is a 
>matter of good practice (in the sense of BCP) rather than a 
>normative feature?

It's not just good practice. Some agents screw up the display of long 
lines as to make them unreadable to the user, and that's an 
interoperation problem. I believe some old ones actually choked on 
long lines (see below).

>Where did that '78' come from? I am aware of lots of systems that do 
>horrid things such as you mention if there are 80 characters in a 
>line, but I am aware of none where problems arise with exactly 79. 
>In other fora where I have seen this discussed, the consensus was 
>that exceeding '79' was the signal for troubles to start.

My memory (and you may wish to search through the DRUMS archive; I'm 
not so motivated at the moment) was that there were some old systems 
that had fixed 80 character records which had room for 78 plus the CR 
plus the LF. 78 was considered the safest.

>  >   Each header field should be
>  >   treated in its unfolded form for further syntactic and semantic
>                                              ^^^^^^^^^
>>    evaluation.
>
>'Semantic' yes, but why is that 'syntactic' there?

OK, I see what you're asking. You're saying that if you want to 
syntactically see whether something is an address, it may contain 
folding (syntactically), so there's no need to unfold to do 
"syntactic evaluation". I was thinking of, "You can't just randomly 
choose some line in a message and see if it's syntactically a 
legitimate field, because that line might be the result of a fold". 
(*Shrug*) I can't get excited about making a change.

>  >3.2.2.  Quoted characters
>
>We have already noted that no-fold-quote, and no-fold-literal can go.

No-fold-quote is gone in message-id (though still accepted in the 
obs- syntax). I am still not sure what to do about no-fold-literal.

>But, as I have pointed out in a separate thread, you would remove a 
>severe interoperability problem with Netnews if you removed it from 
><dcontent> as well (allowing just a "\" to appear as a normal 
>character).

There are too many implementations that have a dcontent (and qcontent 
and ccontent) parser that will not deal with free "\" in any such 
construct. So the only thing we could do would be to abolish "\" 
completely in dcontent. And this is a path that I think would be 
terrible to start down. So, no, I don't think we can make this change.

>  >   within the range -9959 through +9959.
>
>why not "within the range -2359 through +2359"?

I invite you to write up the review of the DRUMS discussion on this, 
provide text, and tell us why we should change it.

>  >   Because the list of mailboxes can be empty, using the group construct
>  >   is also a simple way to communicate to recipients that the message
>>    was sent to one or more named sets of recipients, without actually
>>    providing the individual mailbox address for each of those
>>    recipients.
>
>s/each of/any of/ or s/each of/some of/

Done.

>  >   A liberal syntax
>  >   for the domain portion of addr-spec is given here; it is left to
>  >   other specifications (e.g., [RFC1034], [RFC1035], [RFC1123],
>  >   [I-D.klensin-rfc2821bis]) to give more precise limitations on the
>>    syntax.
>
>Can we strengthen that by saying that the 'liberal syntax' MUST be 
>further restricted to conform to some published specification such 
>as the ones you have listed (without precluding further such 
>specifications in the future, of course)?

Like Ned, I'm opposed to the MUST, but would this suffice (and get us 
out of having to change the syntax for dcontent for message-id if we 
do a similar thing there)?

"Note: A liberal syntax for the domain portion is given here. 
However, the domain portion of addr-spec contains addressing 
information used in other protocols (e.g., [RFC1034], [RFC1035], 
[RFC1123], [I-D.klensin-rfc2821bis]). It is therefore incumbent upon 
implementations to conform to the syntax of addresses for the context 
in which they are used."

It's relatively strong language, but stops short of a compliance 
statement that, as Ned said, could only be satisfied by consulting an 
incomplete and open-ended series of other specifications.

>There may be other transport mechanisms than I-D.klensin-rfc2821bis. 
>So it would be better to say "is covered in separate documents such 
>as [I-D.klensin-rfc2821bis]".

No problem.

>Why is Keywords unlimited (in Netnews it is 1)?

I don't know, and I don't know for Comments either. Anyone? Is it 
worth changing?

>...some people 'munge' their From: addresses in order to appear 
>anonymous, or to confuse address harvesters. Whether that is a 
>desirable practice or not is none of our business, but a normative 
>interpretation of those words would seem to rule it out.
>[...]
>  >   In all cases, the "From:" field SHOULD NOT contain any mailbox that
>>    does not belong to the author(s) of the message.  See also section
>>    3.6.3 for more information on forming the destination addresses for a
>  >   reply.

Wanting to appear anonymous or confuse address harvesters seems 
squarely in the category of "there may exist valid reasons in 
particular circumstances when the particular behavior is acceptable 
or even useful, but the full implications should be understood and 
the case carefully weighed before implementing any behavior described 
with this label." [RFC 2119] So, the normative language seems good as 
well as the potential violation.

>  >   The destination fields specify the recipients of the message.  Each
>>    destination field may have one or more addresses, and each of the
>>    addresses indicate the intended recipients of the message.  The only
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>               indicates an intended recipient

Got it.

>  >   "References:" field may be used to identify a "thread" of
>                         ^^^^^^
>                        is often

Why?

>It would be useful to mention that when the References field gets 
>too long it MAY be pruned (the minimum requirement being to retain 
>the first and the last two entries - including the one just being 
>added). I have known of cases where References fields grew to such a 
>length (and MUAs in the followup chain had failed to introduce 
>folding, or even removed folding already present) that the 998 limit 
>was breached with disastrous consequences.

I am loathe to put in pruning instructions at this point, and without 
such instructions, I don't see what else to say.

>It would be useful to say here that two msg-ids can always be 
>compared for equality by a simple octet-by-octet comparison (but, of 
>course, one would first have to ensure that property was true).

I also don't want to put threading instructions into this document, 
which is the path the above starts down.

>so if, instead of
>     the string "Re: " (from the Latin "res", in the matter of)
>you write
>     the string "Re: " (an abbreviation of the Latin "in re", meaning "in
>     the matter of")
>all will be correct.

OK.

>  >   The "Received:" field contains a
>  >   (possibly empty) list of tokens followed by a semicolon and a date-
>>    time specification.  Each token must be a word, angle-addr, addr-
>  >   spec, or a domain.
>
>Can be find a better word instead of "token" here? "Token" usually 
>means some sort of keyword (e.g. as used in the MIME standards).

I kinda like "token". "Lexeme" seems too syntactic. "Item" seems too generic.

>  >3.6.8.  Optional fields
>>
>  >   Fields may appear in messages that are otherwise unspecified in this
>  >   document.  They MUST conform to the syntax of an optional-field.
>>    This is a field name, made up of the printable US-ASCII characters
>  >   except SP and colon, followed by a colon, followed by any text which
>  >   conforms to unstructured.
>
>This is misleading, because it has to cover all new header fields 
>introduced by extensions and these will be, in general, structured.

That's not what that says. It says that it will conform to unstructured syntax.

>  >4.  Obsolete Syntax
>>
>>    Earlier versions of this specification allowed for different (usually
>>    more liberal) syntax than is allowed in this version.  Also, there
>>    have been syntactic elements used in messages on the Internet whose
>>    interpretation have never been documented.  Though some of these
>     ^^^^^^^^^^^^^^                                     ^^^^
>     interpretations                             Eh? I thought none of them
>                                                 was to be generated.

OK. I'll fix those.

>  >      Note: The "period" (or "full stop") character (".") in obs-phrase
>
>But this is not an "obsolete" construct. We discussed this around 12 
>months ago, and the consensus then was that it ought to be renamed 
>as an <extended-phrase>, and moved out of the Obsolete Syntax.

There was no such consensus; you were the only one who ever suggested 
it on this list. And I still see no reason to change it (as I stated 
back then).

>The syntax given for these obs-constructs includes also the syntax 
>for their regular counterparts, which makes it very hard work to 
>discover exactly where the difference lies because of the huge 
>redundancy that is introduced. For example, if you had written
>
>    obs-qp        =       "\" %d0
>
>nothing would have changed, but it would be immediately obvious what 
>the difference was.

I will try to fix some of these. Certainly obs-qp is easy. But only 
the obvious ones.

>  >4.3.  Obsolete Date and Time
>
>This lot was particularly difficult to spot the differences.

I'm not sure I understand why. I'd prefer to leave it as is. There 
have been enough bugs in this section already that occurred by trying 
to over-simplify the syntax.

>  >   addition, local-part is allowed to contain quoted-string in addition
>                          ^^                                  ^^^^^^^^^^^
>                         was

"Is" allowed in this syntax.

>  >   to just atom.  Finally, ....
>     ^^^^^^^^^^^^
>     in lieu of any of those period-separated atoms

That's incorrect. You can mix atoms and quoted-strings.

>  >6.  IANA Considerations
>>
>>    This document has no actions for IANA.
>
>Oh yes it does!

Oy. Let me see what I can do about that.

>  >   Messages are delimited in this section between lines of "----".  The
>>    "----" lines are not part of the message itself.
>
>That is indeed an excellent notation. The Bad News is that you have 
>nowhere used it :-( .

I'll try figure out how to do something useful in xml2rfc.

>  >   characters (the double-quote characters appearing as quoted-pair
>>    construct).  ...
>     ^^^^^^^^^
>     constructs

Got it.

>  >   In this message, the "To:" field has a single group recipient named A
>                                                                        ^
>                                                                        "
>>    Group which contains 3 addresses, and a "Cc:" field with an empty
>          ^
>          "

Yup.

>Wouldn't it be better to show a Bcc: header for the "Undisclosed 
>recipients" example?

I don't understand what you mean.

>  >   The above example is aesthetically displeasing, but perfectly legal.
>
>Though legal, you should point out that it contains things that are 
>deprecated by 3.3 and by 3.4.1

Nope. A.5 does not (or shouldn't unless I missed something) contain 
anything not perfectly permissible in 3.3 and 3.4.1.

>RFC 1036 is not actually referenced anywhere in the document.

Removed.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: [email-masked]
Cc: [email-masked]
Date: Thu, 16 Aug 2007 15:12:42 -0700 (PDT)
Subject: Re: Comments on draft-resnick-2822upd-02.txt
To: Charles Lindsey <[email-masked]>
Sender: [email-masked]

> My apologies for not making these comments sooner, but I have now read
> carefully through the whole draft and have encountered various nits and
> niggles. Also various things I do not understand (to which I have raised
> questions) and things which seem a little odd and might be worth thinking
> further about. Also some specific suggestions for improvement (some off
> which, I appreciate, may be hard to incorporate at this late stage). And
> also some plain bugs, which of course must be fixed.

> >                        Internet Message Format
> >                        draft-resnick-2822upd-02
> >
> >Abstract
> >
> >   This document specifies a syntax for text messages that are sent
> >   between computer users, within the framework of "electronic mail"
> >   messages.  This specification is a revision Request For Comments
>                                                ^
>                                                of
> >   (RFC) 2822, which itself superseded Request For Comments (RFC) 822,
> >
> >1.  Introduction
> >
> >1.1.  Scope
> >
> >   This document specifies a syntax only for text messages.  In
> >   particular, it makes no provision for the transmission of images,
> >   audio, or other sorts of structured data in electronic mail messages.
> >   There are several extensions published, such as the MIME document
> >   series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
> >   for the transmission of such data through electronic mail,........

> No mention of RFC 2047, or of RFC 2231?

RFC 2047 specifies a means to include non-ASCII text in email headers and has
essentially nothing to do with the transmission of structured data through
email. So why should it be mentioned in this context?

As for RFC 2231, I suppose an argument can be made that it touches on
transmission of nontext material by providing added labelling options, but it's
frankly a stretch and given 2231's lower standards status I am opposed to
mentioning it here.

> >      Note: This specification is not intended to dictate the internal
> >      formats used by sites, the specific message system features that
> >      they are expected to support, or any of the characteristics of
> >      user interface programs that create or read messages.  In
> >      addition, this document does not specify an encoding of the
> >      characters for either transport or storage; that is, it does not
> >      specify the number of bits used or how those bits are specifically
> >      transferred over the wire or stored on disk.

> That last sentence seems wrong/confusing, given that the document specifies
> everything in terms of US-ASCII, presumably with the intent that US-ASCII
> should be the normal means of interchange over the 'wire' between agents (in
> the absence of explicit agreement otherwise).

What it says seems fairly clear to me: Systems exist that store things in units
other than octets, use counts rather than inline terminators, and so on and so
forth and this document isn't attempting to proscribe such behavior.

In any case, if you want the wording changed I think you'd best suggest
some alternative.

> >1.2.  Notational conventions
> >
> >1.2.3.  Structure of this document
> >
> >   Section 4 of this document specifies an "obsolete" syntax.  There are
> >   references in section 3 to these obsolete syntactic elements.  The
> >   rules of the obsolete syntax are elements that have appeared in
> >   earlier revisions of this specification or have previously been
> >   widely used in Internet messages.  As such, these elements MUST be
> >   interpreted by parsers of messages in order to be conformant to this
> >   specification.  However, since items in this syntax have been
> >   determined to be non-interoperable or to cause significant problems
> >   for recipients of messages, they MUST NOT be generated by creators of
> >   conformant messages.

> Can we be clear about the _intent_ of this obs-syntax?

> Is the intent to be able to read/display/print ancient messages which
> people still have on file? In which case, please can we say that there is
> no longer any expectation that obs messages can still be transmitted and
> delivered (by RFC2821 or otherwise), and hence only MUAs (but not MTAs)
> are REQUIRED to accept them.

> Or, alternatively, is the intent that some ancient software still
> generates messages using the obs-syntax, and hence MTAs MUST still accept
> them? In which case, for how much longer?

I see little if any justification for additional elaboration of the intent
here. As far as I'm oncerned the intent covers both your "alternatives' and
quite a few other things as well.

More generally, the problem with trying to nail down intent is that once you do
so the ability of the construct to meet other, as-yet-unplanned needs may be
compromised. See below for an example of another possible use of the obs-
syntax - helping with interop requirements - should we make our own lives
harder down the road simply because this document didn't say that one
intent of this was to make feature enumeration easier?

> Moreover, does it make sense to distinguish between obs constructs that
> were theoretically permitted by RFC822 but in practice never seen in the
> wild, as opposed to those which actually saw significant usage at one
> time? IOW what possibilities exist for the eventual removal of at least
> some of the weirder obs constructs?

The grammar is always quite complex and confusing. Adding another splitting
point would make it even more complex and confusing. Additionally, I really
don't think we need yet another round of interminable arguing over whether or
not some system that hasn't been seen or heard of in several decades did such
and such or so and so.

I will also point out that the obsolete syntax split will be very helpful if we
have to engage in a supported feature enumeration exercise as part of moving to
draft standard. As it stands all we would have to do is demonstrate that
support exists to consume this junk, not produce it. Identification of some
subset of obsolete features that are supposedly never used could easily
bring up the question of whether or not such features should be removed
completely, which I fear would unavoidably send us straight down a huge
rathole.

So, while I get your point and see some benefit to tracking the implementation
status of obsolete features (and non-obsolete ones as well), I don't believe
the benefits of doing so exceed the costs. If this is to be done it should be
done in some other document or perhaps just a web page. 

(Incidentally, I suspect that any such collection exercise will, if conducted
properly, surprise you in how many of the festures you haven't seen personally
were actually used some time and some where. But that's just a guess on my
part.)

> >2.  Lexical Analysis of Messages
> >
> >2.1.  General Description
> >
> >
> >      Note: This document specifies that messages are made up of
> >      characters in the US-ASCII range of 1 through 127.  There are
> >      other documents, specifically the MIME document series ([RFC2045],
> >      [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
> >      extend this specification to allow for values outside of that
> >      range. ...

> It is likely that the extensions from the EAI WG will shortly be added to
> that list. Any possibility of a mention now?

Given that EAI is chartered to produce expermental specifications, IMO a
mention here is really not appropriate.

> >2.1.1.  Line Length Limits
> >
> >   There are two limits that this specification places on the number of
> >   characters in a line.  Each line of characters MUST be no more than
> >   998 characters, and SHOULD be no more than 78 characters, excluding
> >   the CRLF.

> Can we de-emphasise that SHOULD, and make it clear that this is a matter
> of good practice (in the sense of BCP) rather than a normative feature?

That would be a significant change in normative language from RFC 2822 and
could easily be seen as requiring a reset to proposed  Moreover, if memory
serves, this language went into RFC 2822 not because the WG wanted it but
rather because the IESG insisted on it.

The specific member of the IESG that insisted on it is gone now, but the
sentiment behind the requirement may live on for all I know.

Besides, I think a SHOULD is actually appropriate here. SHOULD means you should
do it unless you have a really good reason not to.

> Perhaps s/SHOULD/should/? Too many agents have used this as an excuse to
> rewrite lines en route (maybe there should be a SHOULD NOT for that).

If so, they are relying on a flagrant misreading of the document. Attempting to
prevent such exercises is itself and exercise in futility - the best you can
ever do is point out that the claim isn't supported by the actual language.

As for having a SHOULD NOT about agents altering messages in transit, IMO the
place for that - assuming it makes sense to do - would be the SMTP
specification, not here.

> Perhaps also some informative reference to 'format=flowed' might be in
> order.

That cannot be done meaningfully without also referring to MIME. While the
present layering of these specification is awkward when it comes to stuff like
this, I  think having all sorts of informational cross references would confuse
as much as it clarifies.

> >   The more conservative 78 character recommendation is to accommodate
> >   the many implementations of user interfaces that display these
> >   messages which may truncate, or disastrously wrap, the display of
> >   more than 78 characters per line, in spite of the fact that such
> >   implementations are non-conformant to the intent of this
> >   specification (and that of [I-D.klensin-rfc2821bis] if they actually

> Where did that '78' come from? I am aware of lots of systems that do
> horrid things such as you mention if there are 80 characters in a line,
> but I am aware of none where problems arise with exactly 79. In other fora
> where I have seen this discussed, the consensus was that exceeding '79'
> was the signal for troubles to start.

I've always felt that the 78 character limit was one byte lower than it really
needed to be. But I a long way from convinced that now is the time to change
this.

> >2.2.  Header Fields
> >
> >2.2.3.  Long Header Fields
> >
> >   The process of moving from this folded multiple-line representation
> >   of a header field to its single line representation is called
> >   "unfolding".  Unfolding is accomplished by simply removing any CRLF
> >   that is immediately followed by WSP.  Each header field should be
> >   treated in its unfolded form for further syntactic and semantic
>                                              ^^^^^^^^^
> >   evaluation.

> 'Semantic' yes, but why is that 'syntactic' there?

Don't you have to parse things like address fields in order to then perform
semantic analysis? Syntactic not only seems appropriate, IMO it would be an
error not to have it.

> >2.3.  Body
> >
> >   o  Lines of characters in the body MUST be limited to 998 characters,
> >      and SHOULD be limited to 78 characters, excluding the CRLF.

> Again, that 'SHOULD' is a matter of BCP.

Same argument as before.

> >3.  Syntax
> >
> >
> >3.2.  Lexical Tokens
> >
> >      Note: Readers of this specification need to pay special attention
> >      to how these lexical tokens are used in both the lower-level and
> >      higher-level syntax later in the document.  Particularly, the
> >      white space tokens and the comment tokens defined in section 3.2.3
> >      get used in the lower-level tokens defined here, and those lower-
> >      level tokens are in turn used as parts of the higher-level tokens
> >      defined later.  Therefore, the white space and comments may be
> >      allowed in the higher-level tokens even though they may not
> >      explicitly appear in a particular definition.

> All of which can be _exceedingly_ confusing. There was much discussion on
> this list about 12 months ago about an alternative syntactic improvement
> suggested by Bruce Lily, and I thought we had reached a consensus then to
> bring it in. It is possible, even at this late stage, to do so?

I agree with that it is confusing. Howevver, I did not find Bruce's alternative
helped matters all that much. Nor do I recall any strong consensus to bring it
in. In fact what I recall is almost exactly the opposite: That since we're
attempting to move to draft now we would make every effort to keep the changes
to the absolute minimum. A wholesale change to the grammar doesn't even come
close to meeting that goal.

> >3.2.2.  Quoted characters
> >
> >
> >      Note: The "\" character may appear in a message where it is not
> >      part of a quoted-pair.  A "\" character that does not appear in a
> >      quoted-pair is not semantically invisible.  The only places in
> >      this specification where quoted-pair currently appears are
> >      ccontent, qcontent, dcontent, no-fold-quote, and no-fold-literal.

> We have already noted that no-fold-quote, and no-fold-literal can go. But,
> as I have pointed out in a separate thread, you would remove a severe
> interoperability problem with Netnews if you removed it from <dcontent> as
> well (allowing just a "\" to appear as a normal character).

As I believe I stated in an earler response, I am opposed to removing it. It is
simply not possible to know everything that's out there and just because we
don't know about something is no excuse to break it.  I could live with moving
it to the obsolete syntax but that's as far as I'll go.

> >3.2.3.  Folding white space and comments
> >
> >   Strings of characters enclosed in parentheses are considered comments
> >   so long as they do not appear within a "quoted-string", as defined in
> >   section 3.2.5.  Comments may nest.

> That is not strictly correct, as a "\)" may appear in a <comment> without
> closing the comment.

But that's a literal, no an enclosing parentheses. I really don't think making
the text explicit about this case will clarify things, but again, if you have
text to suggest...

> >ctext           =       NO-WS-CTL /     ; Non white space controls
> >                                        ;
> >                        %d33-39 /       ; The rest of the US-ASCII
> >                        %d42-91 /       ;  characters not including "(",
> >                        %d93-126        ;  ")", or "\"

> Do you _really_ want to permit NO-WS-CTL in a <comment>?

RFC 2822 did, so the question becomes one of do we want to change
this away from what 2822 said?

Like it or not, control characters have long been allowed in a lot of places
where they really don't belong. I remain to be convinced that this one
narrow case is worth worrying about.

> >   Throughout this specification, where FWS (the folding white space
> >   token) appears, it indicates a place where folding, as discussed in
> >   section 2.2.3, may take place.  Wherever folding appears in a message
> >   (that is, a header field body containing a CRLF followed by any WSP),
> >   unfolding (removal of the CRLF) is performed before any further
> >   lexical analysis is performed on that header field according to this
> >   specification.  That is to say, any CRLF that appears in FWS is
> >   semantically "invisible."

> Eh? That seems to be confusing "lexical analysis" with "semantic
> analysis". If it had said "before any semantic analysis is performed" I
> would have understood it.

I agree - "semantic" would better here.

> >3.2.5.  Quoted strings

> > qtext           =       NO-WS-CTL /     ; Non white space controls
> >                                         ;
> >                         %d33 /          ; The rest of the US-ASCII
> >                         %d35-91 /       ;  characters not including "\"
> >                         %d93-126        ;  or the quote character

> Again, do you really want to permit NO-WS-CTL in a <quoted-string>?

Same response.

> >3.2.6.  Miscellaneous tokens
> >
> >   Three additional tokens are defined, word and phrase for combinations
> >   of atoms and/or quoted-strings, and unstructured for use in
> >   unstructured header fields and in some places within structured
> >   header fields.
> >
> >   word            =       atom / quoted-string
> >
> >   phrase          =       1*word / obs-phrase
> >
> >   utext           =       NO-WS-CTL /     ; Non white space controls
> >                           %d33-126        ; The rest of US-ASCII
> >
> >   unstructured    =       (*([FWS] utext) *WSP) / obs-unstruct

> <phrase>s, <unstructured>s and <comment>s are the places where RFC 2047
> raises its ugly head. It is the most confusingly written RFC I have
> encountered (and it could be considered as separate from the rest of
> the MIME standards, since it can be used without the MIME-Version header).

> For a truly outrageous suggestion, we might incorporate the whole of RFC
> 2047 into here, cleaning it up in the process. No, that is too much to
> propose at this juncture, but there are a couple of lesser things we might
> do to help:

> 1. Include <encoded-word> in the syntax at all the proper places (which
> might at least encourage inventors of new extension headers to follow
> suit). It would need a convincing explanation, of course.

I am strongly opopsed to this. If RFC 2047 is confusing, the time to argue that
is when it is revised. We cannot fix it's problems (assuming there actually are
any to fix) by incorporating some subset of references to it in another
document.

> 2. And if that is a step too far, we could still point out that sequences
> of the form "=? ... ? ... ? ... ?=" have a special significance within RFC
> 2047 (whether they exceed that 76 character limit or not), and that such
> sequences SHOULD NOT be used within <phrase>s, <unstructured>s and
> <comment>s unless that special significance is intended.

An informational reference to RFC 2047 would be OK with me.

> >3.3.  Date and Time Specification

> >   A date-time specification MUST be semantically valid.  That is, the
> >   day-of-week (if included) MUST be the day implied by the date, the
> >   numeric day-of-month MUST be between 1 and the number of days allowed
> >   for the specified month (in the specified year), the time-of-day MUST
> >   be in the range 00:00:00 through 23:59:60 (the number of seconds
> >   allowing for a leap second; see [RFC1305]), and the zone MUST be
> >   within the range -9959 through +9959.

> why not "within the range -2359 through +2359"?

I have no objection to restricting the range, but whatever we do needs to agree
with other specifications that deal in time zones. RFC 3339 appears to allow
-2459 through +2459. 

> >3.4.  Address Specification

> >   When it is desirable to treat several mailboxes as a single unit
> >   (i.e., in a distribution list), the group construct can be used.
> >    ...
> >   Because the list of mailboxes can be empty, using the group construct
> >   is also a simple way to communicate to recipients that the message
> >   was sent to one or more named sets of recipients, without actually
> >   providing the individual mailbox address for each of those
> >   recipients.

> s/each of/any of/ or s/each of/some of/

Agreed.

> >3.4.1.  Addr-spec specification
> >
> >   An addr-spec is a specific Internet identifier that contains a
> >   locally interpreted string followed by the at-sign character ("@",
> >   ASCII value 64) followed by an Internet domain.  The locally
> >   interpreted string is either a quoted-string or a dot-atom.  If the
> >   string can be represented as a dot-atom (that is, it contains no
> >   characters other than atext characters or "." surrounded by atext
> >   characters), then the dot-atom form SHOULD be used and the quoted-
> >   string form SHOULD NOT be used.  Comments and folding white space
> >   SHOULD NOT be used around the "@" in the addr-spec.  A liberal syntax
> >   for the domain portion of addr-spec is given here; it is left to
> >   other specifications (e.g., [RFC1034], [RFC1035], [RFC1123],
> >   [I-D.klensin-rfc2821bis]) to give more precise limitations on the
> >   syntax.

> Can we strengthen that by saying that the 'liberal syntax' MUST be further
> restricted to conform to some published specification such as the ones you
> have listed (without precluding further such specifications in the future,
> of course)?

No, because that would usurp the perogative of other specifications to
specify what conformances criteria apply to their additional restrictions.

More generally, it strikes me as a really bad idea to have a MUST for which
compliance can only be determined by consulting an incomplete and open-ended
series of other specifications. This in effect would make it impossible to be
able to claim you have a compliant implementation since you cannot possibly
know when another specfication would be added to this list.

> >dcontent        =       dtext / quoted-pair
> >
> >dtext           =       NO-WS-CTL /     ; Non white space controls
> >                                        ;
> >                        %d33-90 /       ; The rest of the US-ASCII
> >                        %d94-126        ;  characters not including "[",
> >                                        ;  "]", or "\"

> I have already pointed out, in a separate thread, the severe
> interoperability problems with Netnews of this definition of <dcontent>
> (at least insofar as its use within <msg-id> is concerned). The
> troublesome items are <quoted-pair>, NO-WS-CTL, SP and ">" (though "\" in
> dtext would be OK). My suggestion for restricting the 'liberal syntax'
> above was also directed at mitigating this problem.

And IMO you failed to achieve sufficient support to result in a specification
change. As I said previously, I can live with making the use of quoted-pairs in
dtext part of the obsolete syntax, but that's as far as I can see us going.

The alternative approach I actually favor is one I have previously described:
Add some text that says that domain literals in message ids should be generated
using the most restrictive syntax and with well-defined semantics, i.e. an IPv4
or IPv6 literal. To mind the bigger problem here is that someone will generate
something like [foobar] here instead of putting in an actual global IPv4 or
IPv6 address. If we encourage people to use domain literals with defined
semantics we solve several problems at one go.

> >   ....  In both cases, how addressing is
> >   used and how messages are transported to a particular host is covered
> >   in [I-D.klensin-rfc2821bis].  These mechanisms are outside of the
> >   scope of this document.

> There may be other transport mechanisms than I-D.klensin-rfc2821bis. So it
> would be better to say "is covered in separate documents such as
> [I-D.klensin-rfc2821bis]".

I don't feel strongly about this either way.

> >3.5.  Overall message syntax
> >
> >   A message consists of header fields, optionally followed by a message
> >   body.  Lines in a message MUST be a maximum of 998 characters
> >   excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
> >   characters excluding the CRLF. ...

> Again, that is a matter of BCP. "recommended" would be quite strong
> enough.

Again, such recommendaations are what SHOULDs and RECOMMENDED are for and I'm
opposed to making such a change at this point.

> >3.6.  Field definitions
> >
> >   The header fields of a message are defined here.  All header fields
> >   have the same general syntactic structure: A field name, followed by
> >   a colon, followed by the field body.  The specific syntax for each
> >   header field is defined in the subsequent sections.

> I have already pointed out, in a separate thread, the severe
> interoperability problem that arises with Netnews if you do not require a
> SP after the colon. Since every MUA I am aware of routinely inserts that
> SP, I cannot see that anything would be lost by requiring it here.

And as I commented previously, not everything that has an submissiion client in
it is an MUA. There are quick and dirty submission clients embedded in all
sorts of places - one of the advantages of SMTP is that you can code a quick
and dirty client very easily - and leaving out every possible character is
exactly the sort of things these gizmos do. Heck, they  even do it when they've
actually got plenty of space to space - unnecessary optimization is RAMPANT in
the embedded systems world.

I am therefore strongly opposed to disenfranchising such systems.

> >   |                |        |            |                            |
> >   | keywords       | 0      | unlimited  |                            |
> >   |                |        |            |                            |

> Why is Keywords unlimited (in Netnews it is 1)? It is no big deal since
> this field is so seldom used. But its presumed intended use of indexing
> collections of email messages using this field would be simplified if only
> one occurrence was allowed (the obs syntax would still allow multiple
> occurrences, of course, and wording similar to that in 4.5.3 could be
> used).

I could live with such a change, but OTOH I'm not sure I see much point in
making it. The same set of arguments that it doesn't have an impact also make a
case for leaving it alone.

> >3.6.2.  Originator fields

> >   The originator fields indicate the mailbox(es) of the source of the
> >   message.  The "From:" field specifies the author(s) of the message,
> >   that is, the mailbox(es) of the person(s) or system(s) responsible
> >   for the writing of the message....

> Are those sentences intended to be normative, BCP (or even deliberately
> vague :-) ).

Don't see any capitalized words there, do you? So I guess there are
no compliance implications.

> For example, some people 'munge' their From: addresses in order to appear
> anonymous, or to confuse address harvesters. Whether that is a desirable
> practice or not is none of our business, but a normative interpretation of
> those words would seem to rule it out. I might well agree that it is not
> BCP, but it happens.

> The wording currently proposed by the USEFOR WG for this is:

>    Contrary to [RFC2822], which implies that the mailbox or mailboxes in
>    the From header field should be that of the poster or posters, a
>    poster who does not, for whatever reason, wish to use his own mailbox
>    MAY use any mailbox ending in the top level domain ".invalid"
>    [RFC2606].

> But if RFC2822 does not actually imply that, then we might have to think
> again.

And IMO it should not imply that. The last thing email needs at this point is
more license to use invalid addresses.

> Or maybe this issue really belongs under Security Considerations?

> >   In all cases, the "From:" field SHOULD NOT contain any mailbox that
> >   does not belong to the author(s) of the message.  See also section
> >   3.6.3 for more information on forming the destination addresses for a
> >   reply.

> Hmmm! That has a distinctly normative feel to it :-( .

There are capitalized words there so it isn't just a feeling. And IMO those
words are, if anything, too weak.

> >3.6.3.  Destination address fields
> >

> >   The destination fields specify the recipients of the message.  Each
> >   destination field may have one or more addresses, and each of the
> >   addresses indicate the intended recipients of the message.  The only
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>               indicates an intended recipient

Seems reasonable.

> >   difference between the three fields is how each is used.

> >3.6.4.  Identification fields
> >
> >   The "Message-ID:" field contains a single unique message identifier.
> >   The "References:" and "In-Reply-To:" field each contain one or more
> >   unique message identifiers, optionally separated by CFWS.
>                                 ^^^^^^^^^^

> Interoperability with Netnews would be improved without that "optionally".

Perhaps, but like it or not Netnews compatibility is not our primary goal here.

> AFAICS all current MUAs routinely include some WSP there (probably
> because they are following the lead of RFC 1036).

At one point I actually had to change our parser to handle the case where there
was no space there, so I'm fairly sure that not everything out there inserts
the spaces.

> >  no-fold-literal =       "[" *dcontent "]"

> As already mentioned, the present definition of dcontent causes severe
> interoperability problems with Netnews.

Yes, and your repetition of the point without further concrete arguments in
favor or making the change is if anything weakening your case, not
strengthening it.

> >   The "In-Reply-To:" and "References:" fields are used when creating a
> >   reply to a message.  ..., while the
> >   "References:" field may be used to identify a "thread" of
>                         ^^^^^^
>                        is often
> >   conversation.
> >
> >   The "References:" field will contain the contents of the parent's
> >   "References:" field (if any) followed by the contents of the parent's
> >   "Message-ID:" field (if any).  If the parent message does not contain
> >   a "References:" field but does have an "In-Reply-To:" field
> >   containing a single message identifier, then the "References:" field
> >   will contain the contents of the parent's "In-Reply-To:" field
> >   followed by the contents of the parent's "Message-ID:" field (if
> >   any).  If the parent has none of the "References:", "In-Reply-To:",
> >   or "Message-ID:" fields, then the new message will have no
> >   "References:" field.

> It would be useful to mention that when the References field gets too long
> it MAY be pruned (the minimum requirement being to retain the first and
> the last two entries - including the one just being added). I have known
> of cases where References fields grew to such a length (and MUAs in the
> followup chain had failed to introduce folding, or even removed folding
> already present) that the 998 limit was breached with disastrous
> consequences.

Adding such a suggestion would be fine with me were it not for the context of
this effort - every such change increases the likelihood of a problem getting
to draft.

> >   The message identifier (msg-id) itself MUST be a globally unique
> >   identifier for a message.  ...

> It would be useful to say here that two msg-ids can always be compared for
> equality by a simple octet-by-octet comparison (but, of course, one would
> first have to ensure that property was true).

But that's exactly the problem, isn't it? The property is NOT guaranteed
at the present time.

> >   .....  Since the msg-id has
> >   a similar syntax to addr-spec (identical except that comments and
> >   folding white space are not allowed), a good method ...
>                        ^
>            and quoted-strings
>           (as already noted)

Seems OK to make this change.

> >3.6.5.  Informational fields
> >
> >   The informational fields are all optional.  The "Subject:" and
> >   "Comments:" fields are unstructured fields as defined in section
> >   2.2.1, and therefore may contain text or folding white space.  The
> >   "Keywords:" field contains a comma-separated list of one or more
> >   words or quoted-strings.

> That last sentence is redundant, because a <word> cam already be a
> <quoted-string>.

The problem is that it isn't clear whether this refers to the generic idea of a
word or the specific ABNF production for word. So, while it may be somewhat
redundant, I thknk it is actually clearer the way it is.

> >   subject         =       "Subject:" unstructured CRLF
> >
> >   comments        =       "Comments:" unstructured CRLF
> >
> >   keywords        =       "Keywords:" phrase *("," phrase) CRLF

> Why did Organization get left out? It is a defined field within Netnews,
> but it is also already widely used within Email.

Organzation was not defined in either RFC 822 or RFC 2822. According the IANA
registry it is only defined in Netnews, but regardless of other places it is
defined not is absolutely not the time to be adding it to the 822 family of
specifications.

> >   ....  When used in a reply, the field body MAY start with the
> >   string "Re: " (from the Latin "res", in the matter of) followed by
> >   the contents of the "Subject:" field body of the original message.

> If we are going to discuss Latin Grammar, then please let us to so
> correctly. "Res" is the nominative form of the fifth declension noun
> meaning "thing", "matter", "issue", etc.  "Re" is an abbreviation of the
> phrase "in re" meaning "in the matter of", and in which "re" is the
> ablative form of the same noun (the preposition "in" is always followed by
> an ablative in static cases such as this, though it takes the accusative
> form - e.g. "in rem" - in dynamic cases where the meaning is "into").

> so if, instead of
>     the string "Re: " (from the Latin "res", in the matter of)
> you write
>     the string "Re: " (an abbreviation of the Latin "in re", meaning "in
>     the matter of")
> all will be correct.

Yep, now that I think about it you're correct. This is a reasonable change.
Alternately, the  whole thing about the Latin could be omitted.

> >   ....  The
> >   "Keywords:" field contains a comma-separated list of important words
> >   and phrases that might be useful for the recipient.

> Actually, its main intent was to be picked up by search engines and the
> like (agreed, the search engine might belong to the recipient).

Um, not hardly. The definition and use of keywords in email dates back to the
mid 70s, long before storage was cheap enough to waste on compiling indices of
interpersonal or even list mail. At that point the intent really was to aid the
recipient in classifying messages, nothing more and nothing less.

In any case, since "useful to the recipient" seems to cover search engines as
well as countless other uses, I really don't see much need for additional
elaboration here.

> >3.6.6.  Resent fields
> >
> >   When resent fields are used, the "Resent-From:" and "Resent-Date:"
> >   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.
> >   "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
> >   identical to "Resent-From:".

> Why the SHOULD for Resent-Message-ID? What evil befalls if it is omitted?

I'm not a big fan of how resent- has been handled in more recent
specifications, but in this particular case I think the intent is obvious: the
message is in some sense "new" to the transport system so having a new id is a
good idea. It's not like there's an id shortage...

> >3.6.7.  Trace fields
> >
> >   The trace fields are a group of header fields consisting of an
> >   optional "Return-Path:" field, and one or more "Received:" fields.
> >   The "Return-Path:" header field contains a pair of angle brackets
> >   that enclose an optional addr-spec.  The "Received:" field contains a
> >   (possibly empty) list of tokens followed by a semicolon and a date-
> >   time specification.  Each token must be a word, angle-addr, addr-
> >   spec, or a domain.  Further restrictions are applied to the syntax of
> >   the trace fields by specifications that provide for their use, such
> >   as [I-D.klensin-rfc2821bis].

> Can be find a better word instead of "token" here? "Token" usually means
> some sort of keyword (e.g. as used in the MIME standards). "Item" or
> "sub-field" are possible alternatives.

I would prefer item as well. But I don't feel strongly about it.

> >3.6.8.  Optional fields
> >
> >   Fields may appear in messages that are otherwise unspecified in this
> >   document.  They MUST conform to the syntax of an optional-field.
> >   This is a field name, made up of the printable US-ASCII characters
> >   except SP and colon, followed by a colon, followed by any text which
> >   conforms to unstructured.
> >
> >   The field names of any optional-field MUST NOT be identical to any
> >   field name specified elsewhere in this document.
> >
> >  optional-field  =       field-name ":" unstructured CRLF
> >
> >  field-name      =       1*ftext
> >
> >  ftext           =       %d33-57 /               ; Any character except
> >                          %d59-126                ;  controls, SP, and
> >                                                  ;  ":".
> >
> >   For the purposes of this specification, any optional field is
> >   uninterpreted.

> This is misleading, because it has to cover all new header fields
> introduced by extensions and these will be, in general, structured. For
> example, does the use of <unstructured> here imply that RFC 2047 may be
> used freely on any header field not defined by this document - clearly
> 2047 was not intended to imply that, but it would not be hard to read it
> that way. Better to invent some new term <foobar> with the same syntax as
> <unstructured>, and then to say in that last sentence that any internal
> structure of a <foobar> has to be defined elsewhere.

> >4.  Obsolete Syntax
> >
> >   Earlier versions of this specification allowed for different (usually
> >   more liberal) syntax than is allowed in this version.  Also, there
> >   have been syntactic elements used in messages on the Internet whose
> >   interpretation have never been documented.  Though some of these
>     ^^^^^^^^^^^^^^                                     ^^^^
>     interpretations                             Eh? I thought none of them
>                                                 was to be generated.

These both seems like good changes to make to me.

> >   syntactic forms MUST NOT be generated according to the grammar in
> >   section 3, they MUST be accepted and parsed by a conformant receiver.

> which begs the question "what is a 'receiver'?" See earlier discussion.

I think this is reasonably clear and I don't see much value in  trying to get
into defining the overall email architecture here. We have another document for
that.

> >   ....  This
> >   allowed many complex forms that have proven difficult for some
> >   implementations to parse.

> Which sounds like a good reason for no longer requiring agents to parse
> them :-( .

Perhaps if this case had been made effectively six years ago. Now is not the
time.

> >4.1.  Miscellaneous obsolete tokens
> >
> >      Note: The "period" (or "full stop") character (".") in obs-phrase
> >      is not a form that was allowed in earlier versions of this or any
> >      other specification.  Period (nor any other character from
> >      specials) was not allowed in phrase because it introduced a
> >      parsing difficulty distinguishing between phrases and portions of
> >      an addr-spec (see section 4.4).  It appears here because the
> >      period character is currently used in many messages in the
> >      display-name portion of addresses, especially for initials in
> >      names, and therefore must be interpreted properly.  In the future,
> >      period may appear in the regular syntax of phrase.

> But this is not an "obsolete" construct. We discussed this around 12
> months ago, and the consensus then was that it ought to be renamed as an
> <extended-phrase>, and moved out of the Obsolete Syntax.

I don't recall the discussion, but even if that was the consensus at the time
we were unaware of the constraints of this revision exercise. I am therefore
opposed to making this change at this point.

> Observe also that threat that it might one day be promoted to the regular
> syntax. Are we ready yet to implement that threat? Probably not, but its
> day will surely come. But it needs to be said in a more conspicuous place,
> not hidden away in a section with "obsolete" in its name.

I agree with the overall sentiment but now is not the time...

> Likewise for <obs-phrase-list), wich is only used in <obs-keywords>. But
> do we really care whether or not you are allowed to write
>     Keywords: Joe Q. Public ?
> >
> >
> >obs-qp          =       "\" (%d0-127)
> >
> >obs-body        =       *((*LF *CR *(obs-text *LF *CR)) / CRLF)
> >
> >obs-text        =       %d0-9 / %d11-12 /       ; %d0-127 except CR and
> >                        %d14-127                ;  LF
> >
> >obs-unstruct    =       *((*LF *CR *(obs-utext *LF *CR)) / FWS)
> >
> >obs-utext       =       %d0-8 / %d11-12 /       ; %d0-127 except CR, LF,
> >                        %d14-31 / %d33-127      ; and white space

> The syntax given for these obs-constructs includes also the syntax for
> their regular counterparts, which makes it very hard work to discover
> exactly where the difference lies because of the huge redundancy that is
> introduced. For example, if you had written

>    obs-qp        =       "\" %d0

> nothing would have changed, but it would be immediately obvious what the
> difference was. Most of the obs-syntax could be re-written in such a
> non-redundant manner, though I grant you there are a few cases which would
> be difficult.

The argument about fixing really obscure issues once again applies.

> >4.3.  Obsolete Date and Time
> >
> >   The syntax for the obsolete date format allows a 2 digit year in the
> >   date field and allows for a list of alphabetic time zone
> >   specifications that were used in earlier versions of this
> >   specification.  It also permits comments and folding white space
> >   between many of the tokens.
> >
> >  obs-day-of-week =       [CFWS] day-name [CFWS]
> >
> >  obs-year        =       [CFWS] 2*DIGIT [CFWS]
> >
> >  obs-day         =       [CFWS] 1*2DIGIT [CFWS]
> >
> >  obs-hour        =       [CFWS] 2DIGIT [CFWS]
> >
> >  obs-minute      =       [CFWS] 2DIGIT [CFWS]
> >
> >  obs-second      =       [CFWS] 2DIGIT [CFWS]
> >
> >  obs-zone        =       (( "+" / "-" ) [CFWS] 4DIGIT) /
>                            ..............

> This lot was particularly difficult to spot the differences. I believe
> that in <obs-hour> the first [CFWS] is unnecessary,

Yes, it appears to be because the trailing [CFWS] in obs-year takes
care of it. I'm not sure that it is worth eliminating, however - it
is entirely possible I've missed something.

> and the [CFWS] at the
> end of <obs-second> might be better moved to the start of <obs-zone>,
> since that reflects better the way FWS is treated in the regular syntax.

Again, seems reasonable, but a bit late in the game to make such changes.

> >4.4.  Obsolete Addressing
> >
> >   There are three primary differences in addressing.  First, mailbox
> >   addresses were allowed to have a route portion before the addr-spec
> >   when enclosed in "<" and ">".  The route is simply a comma-separated
> >   list of domain names, each preceded by "@", and the list terminated
> >   by a colon.  Second, CFWS were allowed between the period-separated
> >   elements of local-part and domain (i.e., dot-atom was not used).  In
> >   addition, local-part is allowed to contain quoted-string in addition
>                          ^^                                  ^^^^^^^^^^^
>                         was
> >   to just atom.  Finally, ....
>     ^^^^^^^^^^^^
>     in lieu of any of those period-separated atoms

Agreed.

> >5.  Security Considerations
> >
> >   Care needs to be taken when displaying messages on a terminal or
> >   terminal emulator.  Powerful terminals may act on escape sequences
> >   and other combinations of ASCII control characters with a variety of
> >   consequences.  They can remap the keyboard or permit other
> >   modifications to the terminal which could lead to denial of service
> >   or even damaged data.  They can trigger (sometimes programmable)
> >   answerback messages which can allow a message to cause commands to be
> >   issued on the recipient's behalf.  They can also affect the operation
> >   of terminal attached devices such as printers.  Message viewers may
> >   wish to strip potentially dangerous terminal escape sequences from
> >   the message prior to display.  However, other escape sequences appear
> >   in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
> >   [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
> >   should not be stripped indiscriminately.

> Eh? what "other escape sequences" do you have in mind? I am not aware of
> any meaningful use of NO-WS-CTLs in any of those standards. OTOH, if that
> list is correct, should RFC 2231 be added to it?

You appear to have NO-WS-CTLs on the brain. This section is pretty clearly
focused on control characters in body text, not headers. And since MIME allows
the use of alternate charsets, some of which make extensive use of ISO 2022
escape sequences, the point about not stripping them indecriminantly seems
especially well taken. Indeed, if memory serves, it is not all that uncommon to
find Asian text in one of these charsets that's been damaged by control
character removal, so much so fixup utilities exist to try and correct such
damage.

> >   Many implementations use the "Bcc:" (blind carbon copy) field
> >   described in section 3.6.3 to facilitate sending messages to
> >   recipients without revealing the addresses of one or more of the
> >   addressees to the other recipients.  Mishandling this use of "Bcc:"
> >   may disclose confidential information which could eventually lead to
> >   security problems through knowledge of even the existence of a
> >   particular mail address.  For example, if using the first method
> >   described in section 3.6.3, where the "Bcc:" line is removed from the
> >   message, blind recipients have no explicit indication that they have
> >   been sent a blind copy, except insofar as their address does not
> >   appear in the message header section.  Because of this, one of the
> >   blind addressees could potentially send a reply to all of the shown
> >   recipients and accidentally reveal that the message went to the blind
> >   recipient.  When the second method from section 3.6.3 is used, the
> >   blind recipient's address appears in the "Bcc:" field of a separate
> >   copy of the message.  If the "Bcc:" field sent contains all of the
> >   blind addressees, all of the "Bcc:" recipients will be seen by each
> >   "Bcc:" recipient.  Even if a separate message is sent to each "Bcc:"
> >   recipient with only the individual's address, implementations still
> >   need to be careful to process replies to the message as per section
> >   3.6.3 so as not to accidentally reveal the blind recipient to other
> >   recipients.

> But how could such revelation be avoided? Surely, if a blind recipient
> replies to any message, his identity will be given away by the From header
> of the reply? I see nothing in 3.6.3 that helps with this problem.

In the case of reply-to-all, sure. But the case this appears to be addressing
is when the reply is being sent to the originator only.  The originator
presumably knows who he or she bcc'ed so nothing is directly revealed by doing
this. However, if the reply manages to promote a bcc address to a Cc or To
field, a reply to that reply could easily reveal the original blind carbon
action.

More generally, it just seems like a good idea to try and keep bcc and other
reipient addresses separate when possible.

> >6.  IANA Considerations
> >
> >   This document has no actions for IANA.

> Oh yes it does!

> RFC 3864 requires IANA to maintain a registry of header fields within
> Email, News and HTTP. Anybody who defines a header field is obliged to
> provide a template for use in that registry.

> In the case of RFC 2822, Graham Klyne wrote a set of templates in RFC
> 4021. But these all reference RFC 2822 as the relevant specification
> document, and so will become outdated as soon as 2822bis appears. On top
> of that, they are all (IMHO) unnecessarily verbose.

> So you need to write a full set of revised templates in here. I suggest
> you look at draft-ietf-usefor-usefor-12 for how we laid out those
> templates for USEFOR (carefullly avoiding such verbosities :-) ).

I'm very much afraid that you are correct about this. I see little choice but
to include such templates in this revision. I'd really rather not if there
was a way out, but I just don't see one.

> >Appendix A.  Example messages
> >
> >   Messages are delimited in this section between lines of "----".  The
> >   "----" lines are not part of the message itself.

> That is indeed an excellent notation. The Bad News is that you have
> nowhere used it :-( .

Yes, and so this sentence would best be removed.

> >Appendix A.1.2.  Different types of mailboxes
> >
> >   This message includes multiple addresses in the destination fields
> >   and also uses several different forms of addresses.
> >
> >   From: "Joe Q. Public" <[email-masked]>
> >   To: Mary Smith <[email-masked]>, [email-masked], Who? <[email-masked]>
> >   Cc: <[email-masked]>, "Giant; \"Big\" Box" <[email-masked]>
> >   Date: Tue, 1 Jul 2003 10:52:37 +0200
> >   Message-ID: <[email-masked]>
> >
> >   Hi everyone.
> >
> >   Note that the display names for Joe Q. Public and Giant; "Big" Box
> >   needed to be enclosed in double-quotes because the former contains
> >   the period and the latter contains both semicolon and double-quote
> >   characters (the double-quote characters appearing as quoted-pair
> >   construct).  ...
>     ^^^^^^^^^
>     constructs

Agreed.

> >Appendix A.1.3.  Group addresses
> >
> > From: Pete <[email-masked]>
> > To: A Group:Chris Jones <[email-masked]>,[email-masked],John <[email-masked]>;
> > Cc: Undisclosed recipients:;
> > Date: Thu, 13 Feb 1969 23:32:54 -0330
> > Message-ID: <[email-masked]>
> >
> > Testing.
> >
> >   In this message, the "To:" field has a single group recipient named A
>                                                                        ^
>                                                                        "
> >   Group which contains 3 addresses, and a "Cc:" field with an empty
>          ^
>          "
> >   group recipient named Undisclosed recipients.

> Wouldn't it be better to show a Bcc: header for the "Undisclosed
> recipients" example?

Not necesarily - it depends on what's intended, and the document is silent on
that. A cc: field with "undisclosed recipients: ;" is  intended to convey the
fact that there are other recipients to everyone who gets the message. Putting
this in a bcc field, which often as not is only included in some message copies
but not others, could be intended to convey that informaation to only a subset
of the recipients. Or it could have have gone to everyone. There's no way
to tell.

> >Appendix A.4.  Messages with trace fields
> >
> >   As messages are sent through the transport system as described in
> >   [I-D.klensin-rfc2821bis], trace fields are prepended to the message.
> >   The following is an example of what those trace fields might look
> >   like.  Note that there is some folding white space in the first one
>                                    ^^^^^^^
>                                    folded
> >   since these lines can be long.

No, this is a term of art, not a description of what's there.

> >Appendix A.5.  White space, comments, and other oddities
> >
> >   White space, including folding white space, and comments can be
> >   inserted between many of the tokens of fields.  Taking the example
> >   from A.1.3, white space and comments can be inserted into all of the
> >   fields.
> >
> >From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
> >To:A Group(Some people)
> >     :Chris Jones <c@(Chris's host.)public.example>,
> >         [email-masked],
> >  John <[email-masked]> (my dear friend); (the end of the group)
> >Cc:(Empty list)(start)Undisclosed recipients  :(nobody(that I know))  ;
> >Date: Thu,
> >      13
> >        Feb
> >          1969
> >      23:32
> >               -0330 (Newfoundland Time)
> >Message-ID:              <[email-masked]>
> >
> >Testing.
> >
> >   The above example is aesthetically displeasing, but perfectly legal.

> Though legal, you should point out that it contains things that are
> deprecated by 3.3 and by 3.4.1, and that agents might well choke on them.

I don't oppose it but OTOH I can't get excited about repeating the warning in
this context.

> >7.  References
> >
> >7.2.  Informative References
> >
> >   [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
> >              USENET messages", RFC 1036, December 1987.

> RFC 1036 is not actually referenced anywhere in the document. Moreover, if
> you DO have a need to reference it (please do :-) ) then you ought to
> refer to draft-ietf-usefor-usefor-12 instead.

The RFC Editor will yank any orphaned (Or is it widowed? Who cares?) references
so this really isn't worth worrying about. If we want to do soemthing about it,
let's remove it entirely.

				Ned

Date: Thu, 16 Aug 2007 16:39:06 -0400 (New York)
From: Gary Welles <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Sender: [email-masked]

Charles Lindsey asks:

> Where did that '78' come from? I am aware of lots of systems that do
> horrid things such as you mention if there are 80 characters in a line,
> but I am aware of none where problems arise with exactly 79. . . .

78 characters plus a <cr><lf> pair make 80 characters.  A 79 
character line would be 81 and some displays advance to a new 
line after 80 resulting in double spaced text.

-- Gary Welles

Date: Wed, 15 Aug 2007 23:11:47 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Comments on draft-resnick-2822upd-02.txt
Sender: [email-masked]

At 14:44 15-08-2007, Charles Lindsey wrote:
> >2.1.1.  Line Length Limits
> >
> >   There are two limits that this specification places on the number of
> >   characters in a line.  Each line of characters MUST be no more than
> >   998 characters, and SHOULD be no more than 78 characters, excluding
> >   the CRLF.
>
>Can we de-emphasise that SHOULD, and make it clear that this is a matter
>of good practice (in the sense of BCP) rather than a normative feature?
>Perhaps s/SHOULD/should/? Too many agents have used this as an excuse to
>rewrite lines en route (maybe there should be a SHOULD NOT for that).

I read that as more than a BCP.  Quoting a message from the 2822 era:

   "The 78 character recommendation is due to limitations in many
    implementations which display these messages which may truncate display
    of more than 78 characters per line. Of course, even though these
    limitations are put on messages, interpreters of messages would do well
    to handle an arbitrarily large number of characters in a line, including
    for display, for robustness' sake."

>Where did that '78' come from? I am aware of lots of systems that do
>horrid things such as you mention if there are 80 characters in a line,
>but I am aware of none where problems arise with exactly 79. In other fora
>where I have seen this discussed, the consensus was that exceeding '79'
>was the signal for troubles to start.

There are 80 characters per line on a text display.  There may be a 
one character border on the left and right hand side.  That leaves 
you with 78 characters.  Some (old) displays do not wrap a long 
line.  Although it may sound obsolete in this day and age, some 
messages may be sent directly to a printer which may have the same line limit.

> >3.3.  Date and Time Specification
>
> >   A date-time specification MUST be semantically valid.  That is, the
> >   day-of-week (if included) MUST be the day implied by the date, the
> >   numeric day-of-month MUST be between 1 and the number of days allowed
> >   for the specified month (in the specified year), the time-of-day MUST
> >   be in the range 00:00:00 through 23:59:60 (the number of seconds
> >   allowing for a leap second; see [RFC1305]), and the zone MUST be
> >   within the range -9959 through +9959.
>
>why not "within the range -2359 through +2359"?

Because the difference can be more than 2359.  If I recall correctly, 
it was something to do with crossing the date line.

Regards,
-sm  

To: [email-masked]
Xref: clerew local.mime:5057
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Comments on draft-resnick-2822upd-02.txt
Date: Wed, 15 Aug 2007 21:44:18 GMT
Lines: 861
Sender: [email-masked]

My apologies for not making these comments sooner, but I have now read
carefully through the whole draft and have encountered various nits and
niggles. Also various things I do not understand (to which I have raised
questions) and things which seem a little odd and might be worth thinking
further about. Also some specific suggestions for improvement (some off
which, I appreciate, may be hard to incorporate at this late stage). And
also some plain bugs, which of course must be fixed.

>                        Internet Message Format
>                        draft-resnick-2822upd-02
>
>Abstract
>
>   This document specifies a syntax for text messages that are sent
>   between computer users, within the framework of "electronic mail"
>   messages.  This specification is a revision Request For Comments
                                               ^
                                               of
>   (RFC) 2822, which itself superseded Request For Comments (RFC) 822,
>
>1.  Introduction
>
>1.1.  Scope
>
>   This document specifies a syntax only for text messages.  In
>   particular, it makes no provision for the transmission of images,
>   audio, or other sorts of structured data in electronic mail messages.
>   There are several extensions published, such as the MIME document
>   series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
>   for the transmission of such data through electronic mail,........

No mention of RFC 2047, or of RFC 2231?
>
>      Note: This specification is not intended to dictate the internal
>      formats used by sites, the specific message system features that
>      they are expected to support, or any of the characteristics of
>      user interface programs that create or read messages.  In
>      addition, this document does not specify an encoding of the
>      characters for either transport or storage; that is, it does not
>      specify the number of bits used or how those bits are specifically
>      transferred over the wire or stored on disk.

That last sentence seems wrong/confusing, given that the document specifies
everything in terms of US-ASCII, presumably with the intent that US-ASCII
should be the normal means of interchange over the 'wire' between agents (in
the absence of explicit agreement otherwise).

>1.2.  Notational conventions
>
>1.2.3.  Structure of this document
>
>   Section 4 of this document specifies an "obsolete" syntax.  There are
>   references in section 3 to these obsolete syntactic elements.  The
>   rules of the obsolete syntax are elements that have appeared in
>   earlier revisions of this specification or have previously been
>   widely used in Internet messages.  As such, these elements MUST be
>   interpreted by parsers of messages in order to be conformant to this
>   specification.  However, since items in this syntax have been
>   determined to be non-interoperable or to cause significant problems
>   for recipients of messages, they MUST NOT be generated by creators of
>   conformant messages.

Can we be clear about the _intent_ of this obs-syntax?

Is the intent to be able to read/display/print ancient messages which
people still have on file? In which case, please can we say that there is
no longer any expectation that obs messages can still be transmitted and
delivered (by RFC2821 or otherwise), and hence only MUAs (but not MTAs)
are REQUIRED to accept them.

Or, alternatively, is the intent that some ancient software still
generates messages using the obs-syntax, and hence MTAs MUST still accept
them? In which case, for how much longer?

Moreover, does it make sense to distinguish between obs constructs that
were theoretically permitted by RFC822 but in practice never seen in the
wild, as opposed to those which actually saw significant usage at one
time? IOW what possibilities exist for the eventual removal of at least
some of the weirder obs constructs?
>
>2.  Lexical Analysis of Messages
>
>2.1.  General Description
>
>
>      Note: This document specifies that messages are made up of
>      characters in the US-ASCII range of 1 through 127.  There are
>      other documents, specifically the MIME document series ([RFC2045],
>      [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
>      extend this specification to allow for values outside of that
>      range. ...

It is likely that the extensions from the EAI WG will shortly be added to
that list. Any possibility of a mention now?

>2.1.1.  Line Length Limits
>
>   There are two limits that this specification places on the number of
>   characters in a line.  Each line of characters MUST be no more than
>   998 characters, and SHOULD be no more than 78 characters, excluding
>   the CRLF.

Can we de-emphasise that SHOULD, and make it clear that this is a matter
of good practice (in the sense of BCP) rather than a normative feature?
Perhaps s/SHOULD/should/? Too many agents have used this as an excuse to
rewrite lines en route (maybe there should be a SHOULD NOT for that).

Perhaps also some informative reference to 'format=flowed' might be in
order.
>
>   The more conservative 78 character recommendation is to accommodate
>   the many implementations of user interfaces that display these
>   messages which may truncate, or disastrously wrap, the display of
>   more than 78 characters per line, in spite of the fact that such
>   implementations are non-conformant to the intent of this
>   specification (and that of [I-D.klensin-rfc2821bis] if they actually

Where did that '78' come from? I am aware of lots of systems that do
horrid things such as you mention if there are 80 characters in a line,
but I am aware of none where problems arise with exactly 79. In other fora
where I have seen this discussed, the consensus was that exceeding '79'
was the signal for troubles to start.

>
>2.2.  Header Fields
>
>2.2.3.  Long Header Fields
>
>   The process of moving from this folded multiple-line representation
>   of a header field to its single line representation is called
>   "unfolding".  Unfolding is accomplished by simply removing any CRLF
>   that is immediately followed by WSP.  Each header field should be
>   treated in its unfolded form for further syntactic and semantic
                                             ^^^^^^^^^
>   evaluation.

'Semantic' yes, but why is that 'syntactic' there?

>2.3.  Body
>
>   o  Lines of characters in the body MUST be limited to 998 characters,
>      and SHOULD be limited to 78 characters, excluding the CRLF.

Again, that 'SHOULD' is a matter of BCP.

>3.  Syntax
>
>
>3.2.  Lexical Tokens
>
>      Note: Readers of this specification need to pay special attention
>      to how these lexical tokens are used in both the lower-level and
>      higher-level syntax later in the document.  Particularly, the
>      white space tokens and the comment tokens defined in section 3.2.3
>      get used in the lower-level tokens defined here, and those lower-
>      level tokens are in turn used as parts of the higher-level tokens
>      defined later.  Therefore, the white space and comments may be
>      allowed in the higher-level tokens even though they may not
>      explicitly appear in a particular definition.

All of which can be _exceedingly_ confusing. There was much discussion on
this list about 12 months ago about an alternative syntactic improvement
suggested by Bruce Lily, and I thought we had reached a consensus then to
bring it in. It is possible, even at this late stage, to do so?

>3.2.2.  Quoted characters
>
>
>      Note: The "\" character may appear in a message where it is not
>      part of a quoted-pair.  A "\" character that does not appear in a
>      quoted-pair is not semantically invisible.  The only places in
>      this specification where quoted-pair currently appears are
>      ccontent, qcontent, dcontent, no-fold-quote, and no-fold-literal.

We have already noted that no-fold-quote, and no-fold-literal can go. But,
as I have pointed out in a separate thread, you would remove a severe
interoperability problem with Netnews if you removed it from <dcontent> as
well (allowing just a "\" to appear as a normal character).
>

>3.2.3.  Folding white space and comments
>
>   Strings of characters enclosed in parentheses are considered comments
>   so long as they do not appear within a "quoted-string", as defined in
>   section 3.2.5.  Comments may nest.

That is not strictly correct, as a "\)" may appear in a <comment> without
closing the comment.

>ctext           =       NO-WS-CTL /     ; Non white space controls
>                                        ;
>                        %d33-39 /       ; The rest of the US-ASCII
>                        %d42-91 /       ;  characters not including "(",
>                        %d93-126        ;  ")", or "\"

Do you _really_ want to permit NO-WS-CTL in a <comment>?

>   Throughout this specification, where FWS (the folding white space
>   token) appears, it indicates a place where folding, as discussed in
>   section 2.2.3, may take place.  Wherever folding appears in a message
>   (that is, a header field body containing a CRLF followed by any WSP),
>   unfolding (removal of the CRLF) is performed before any further
>   lexical analysis is performed on that header field according to this
>   specification.  That is to say, any CRLF that appears in FWS is
>   semantically "invisible."

Eh? That seems to be confusing "lexical analysis" with "semantic
analysis". If it had said "before any semantic analysis is performed" I
would have understood it.

>3.2.5.  Quoted strings

> qtext           =       NO-WS-CTL /     ; Non white space controls
>                                         ;
>                         %d33 /          ; The rest of the US-ASCII
>                         %d35-91 /       ;  characters not including "\"
>                         %d93-126        ;  or the quote character

Again, do you really want to permit NO-WS-CTL in a <quoted-string>?

>3.2.6.  Miscellaneous tokens
>
>   Three additional tokens are defined, word and phrase for combinations
>   of atoms and/or quoted-strings, and unstructured for use in
>   unstructured header fields and in some places within structured
>   header fields.
>
>   word            =       atom / quoted-string
>
>   phrase          =       1*word / obs-phrase
>
>   utext           =       NO-WS-CTL /     ; Non white space controls
>                           %d33-126        ; The rest of US-ASCII
>
>   unstructured    =       (*([FWS] utext) *WSP) / obs-unstruct

<phrase>s, <unstructured>s and <comment>s are the places where RFC 2047
raises its ugly head. It is the most confusingly written RFC I have
encountered (and it could be considered as separate from the rest of
the MIME standards, since it can be used without the MIME-Version header).

For a truly outrageous suggestion, we might incorporate the whole of RFC
2047 into here, cleaning it up in the process. No, that is too much to
propose at this juncture, but there are a couple of lesser things we might
do to help:

1. Include <encoded-word> in the syntax at all the proper places (which
might at least encourage inventors of new extension headers to follow
suit). It would need a convincing explanation, of course.

2. And if that is a step too far, we could still point out that sequences
of the form "=? ... ? ... ? ... ?=" have a special significance within RFC
2047 (whether they exceed that 76 character limit or not), and that such
sequences SHOULD NOT be used within <phrase>s, <unstructured>s and
<comment>s unless that special significance is intended.

>3.3.  Date and Time Specification

>   A date-time specification MUST be semantically valid.  That is, the
>   day-of-week (if included) MUST be the day implied by the date, the
>   numeric day-of-month MUST be between 1 and the number of days allowed
>   for the specified month (in the specified year), the time-of-day MUST
>   be in the range 00:00:00 through 23:59:60 (the number of seconds
>   allowing for a leap second; see [RFC1305]), and the zone MUST be
>   within the range -9959 through +9959.

why not "within the range -2359 through +2359"?

>3.4.  Address Specification

>   When it is desirable to treat several mailboxes as a single unit
>   (i.e., in a distribution list), the group construct can be used.
>    ...
>   Because the list of mailboxes can be empty, using the group construct
>   is also a simple way to communicate to recipients that the message
>   was sent to one or more named sets of recipients, without actually
>   providing the individual mailbox address for each of those
>   recipients.

s/each of/any of/ or s/each of/some of/
>
>3.4.1.  Addr-spec specification
>
>   An addr-spec is a specific Internet identifier that contains a
>   locally interpreted string followed by the at-sign character ("@",
>   ASCII value 64) followed by an Internet domain.  The locally
>   interpreted string is either a quoted-string or a dot-atom.  If the
>   string can be represented as a dot-atom (that is, it contains no
>   characters other than atext characters or "." surrounded by atext
>   characters), then the dot-atom form SHOULD be used and the quoted-
>   string form SHOULD NOT be used.  Comments and folding white space
>   SHOULD NOT be used around the "@" in the addr-spec.  A liberal syntax
>   for the domain portion of addr-spec is given here; it is left to
>   other specifications (e.g., [RFC1034], [RFC1035], [RFC1123],
>   [I-D.klensin-rfc2821bis]) to give more precise limitations on the
>   syntax.

Can we strengthen that by saying that the 'liberal syntax' MUST be further
restricted to conform to some published specification such as the ones you
have listed (without precluding further such specifications in the future,
of course)?
>
>
>dcontent        =       dtext / quoted-pair
>
>dtext           =       NO-WS-CTL /     ; Non white space controls
>                                        ;
>                        %d33-90 /       ; The rest of the US-ASCII
>                        %d94-126        ;  characters not including "[",
>                                        ;  "]", or "\"

I have already pointed out, in a separate thread, the severe
interoperability problems with Netnews of this definition of <dcontent>
(at least insofar as its use within <msg-id> is concerned). The
troublesome items are <quoted-pair>, NO-WS-CTL, SP and ">" (though "\" in
dtext would be OK). My suggestion for restricting the 'liberal syntax'
above was also directed at mitigating this problem.

>   ....  In both cases, how addressing is
>   used and how messages are transported to a particular host is covered
>   in [I-D.klensin-rfc2821bis].  These mechanisms are outside of the
>   scope of this document.

There may be other transport mechanisms than I-D.klensin-rfc2821bis. So it
would be better to say "is covered in separate documents such as
[I-D.klensin-rfc2821bis]".

>
>3.5.  Overall message syntax
>
>   A message consists of header fields, optionally followed by a message
>   body.  Lines in a message MUST be a maximum of 998 characters
>   excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
>   characters excluding the CRLF. ...

Again, that is a matter of BCP. "recommended" would be quite strong
enough.

>3.6.  Field definitions
>
>   The header fields of a message are defined here.  All header fields
>   have the same general syntactic structure: A field name, followed by
>   a colon, followed by the field body.  The specific syntax for each
>   header field is defined in the subsequent sections.

I have already pointed out, in a separate thread, the severe
interoperability problem that arises with Netnews if you do not require a
SP after the colon. Since every MUA I am aware of routinely inserts that
SP, I cannot see that anything would be lost by requiring it here.

>   |                |        |            |                            |
>   | keywords       | 0      | unlimited  |                            |
>   |                |        |            |                            |

Why is Keywords unlimited (in Netnews it is 1)? It is no big deal since
this field is so seldom used. But its presumed intended use of indexing
collections of email messages using this field would be simplified if only
one occurrence was allowed (the obs syntax would still allow multiple
occurrences, of course, and wording similar to that in 4.5.3 could be
used).

>3.6.2.  Originator fields

>   The originator fields indicate the mailbox(es) of the source of the
>   message.  The "From:" field specifies the author(s) of the message,
>   that is, the mailbox(es) of the person(s) or system(s) responsible
>   for the writing of the message....

Are those sentences intended to be normative, BCP (or even deliberately
vague :-) ).

For example, some people 'munge' their From: addresses in order to appear
anonymous, or to confuse address harvesters. Whether that is a desirable
practice or not is none of our business, but a normative interpretation of
those words would seem to rule it out. I might well agree that it is not
BCP, but it happens.

The wording currently proposed by the USEFOR WG for this is:

   Contrary to [RFC2822], which implies that the mailbox or mailboxes in
   the From header field should be that of the poster or posters, a
   poster who does not, for whatever reason, wish to use his own mailbox
   MAY use any mailbox ending in the top level domain ".invalid"
   [RFC2606].

But if RFC2822 does not actually imply that, then we might have to think
again.

Or maybe this issue really belongs under Security Considerations?

>   In all cases, the "From:" field SHOULD NOT contain any mailbox that
>   does not belong to the author(s) of the message.  See also section
>   3.6.3 for more information on forming the destination addresses for a
>   reply.

Hmmm! That has a distinctly normative feel to it :-( .

>3.6.3.  Destination address fields
>

>   The destination fields specify the recipients of the message.  Each
>   destination field may have one or more addresses, and each of the
>   addresses indicate the intended recipients of the message.  The only
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
              indicates an intended recipient
>   difference between the three fields is how each is used.

>3.6.4.  Identification fields
>
>   The "Message-ID:" field contains a single unique message identifier.
>   The "References:" and "In-Reply-To:" field each contain one or more
>   unique message identifiers, optionally separated by CFWS.
                                ^^^^^^^^^^

Interoperability with Netnews would be improved without that "optionally".
AFAICS all current MUAs routinely include some WSP there (probably
because they are following the lead of RFC 1036).

>  no-fold-literal =       "[" *dcontent "]"

As already mentioned, the present definition of dcontent causes severe
interoperability problems with Netnews.

>   The "In-Reply-To:" and "References:" fields are used when creating a
>   reply to a message.  ..., while the
>   "References:" field may be used to identify a "thread" of
                        ^^^^^^
                       is often
>   conversation.
>
>   The "References:" field will contain the contents of the parent's
>   "References:" field (if any) followed by the contents of the parent's
>   "Message-ID:" field (if any).  If the parent message does not contain
>   a "References:" field but does have an "In-Reply-To:" field
>   containing a single message identifier, then the "References:" field
>   will contain the contents of the parent's "In-Reply-To:" field
>   followed by the contents of the parent's "Message-ID:" field (if
>   any).  If the parent has none of the "References:", "In-Reply-To:",
>   or "Message-ID:" fields, then the new message will have no
>   "References:" field.

It would be useful to mention that when the References field gets too long
it MAY be pruned (the minimum requirement being to retain the first and
the last two entries - including the one just being added). I have known
of cases where References fields grew to such a length (and MUAs in the
followup chain had failed to introduce folding, or even removed folding
already present) that the 998 limit was breached with disastrous
consequences.

>   The message identifier (msg-id) itself MUST be a globally unique
>   identifier for a message.  ...

It would be useful to say here that two msg-ids can always be compared for
equality by a simple octet-by-octet comparison (but, of course, one would
first have to ensure that property was true).

>   .....  Since the msg-id has
>   a similar syntax to addr-spec (identical except that comments and
>   folding white space are not allowed), a good method ...
                       ^
           and quoted-strings
          (as already noted)

>3.6.5.  Informational fields
>
>   The informational fields are all optional.  The "Subject:" and
>   "Comments:" fields are unstructured fields as defined in section
>   2.2.1, and therefore may contain text or folding white space.  The
>   "Keywords:" field contains a comma-separated list of one or more
>   words or quoted-strings.

That last sentence is redundant, because a <word> cam already be a
<quoted-string>.
>
>   subject         =       "Subject:" unstructured CRLF
>
>   comments        =       "Comments:" unstructured CRLF
>
>   keywords        =       "Keywords:" phrase *("," phrase) CRLF

Why did Organization get left out? It is a defined field within Netnews,
but it is also already widely used within Email.

>
>   ....  When used in a reply, the field body MAY start with the
>   string "Re: " (from the Latin "res", in the matter of) followed by
>   the contents of the "Subject:" field body of the original message.

If we are going to discuss Latin Grammar, then please let us to so
correctly. "Res" is the nominative form of the fifth declension noun
meaning "thing", "matter", "issue", etc.  "Re" is an abbreviation of the
phrase "in re" meaning "in the matter of", and in which "re" is the
ablative form of the same noun (the preposition "in" is always followed by
an ablative in static cases such as this, though it takes the accusative
form - e.g. "in rem" - in dynamic cases where the meaning is "into").

so if, instead of
    the string "Re: " (from the Latin "res", in the matter of)
you write
    the string "Re: " (an abbreviation of the Latin "in re", meaning "in
    the matter of")
all will be correct.

>   ....  The
>   "Keywords:" field contains a comma-separated list of important words
>   and phrases that might be useful for the recipient.

Actually, its main intent was to be picked up by search engines and the
like (agreed, the search engine might belong to the recipient).
>
>3.6.6.  Resent fields
>
>   When resent fields are used, the "Resent-From:" and "Resent-Date:"
>   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.
>   "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
>   identical to "Resent-From:".

Why the SHOULD for Resent-Message-ID? What evil befalls if it is omitted?

>3.6.7.  Trace fields
>
>   The trace fields are a group of header fields consisting of an
>   optional "Return-Path:" field, and one or more "Received:" fields.
>   The "Return-Path:" header field contains a pair of angle brackets
>   that enclose an optional addr-spec.  The "Received:" field contains a
>   (possibly empty) list of tokens followed by a semicolon and a date-
>   time specification.  Each token must be a word, angle-addr, addr-
>   spec, or a domain.  Further restrictions are applied to the syntax of
>   the trace fields by specifications that provide for their use, such
>   as [I-D.klensin-rfc2821bis].

Can be find a better word instead of "token" here? "Token" usually means
some sort of keyword (e.g. as used in the MIME standards). "Item" or
"sub-field" are possible alternatives.

>3.6.8.  Optional fields
>
>   Fields may appear in messages that are otherwise unspecified in this
>   document.  They MUST conform to the syntax of an optional-field.
>   This is a field name, made up of the printable US-ASCII characters
>   except SP and colon, followed by a colon, followed by any text which
>   conforms to unstructured.
>
>   The field names of any optional-field MUST NOT be identical to any
>   field name specified elsewhere in this document.
>
>  optional-field  =       field-name ":" unstructured CRLF
>
>  field-name      =       1*ftext
>
>  ftext           =       %d33-57 /               ; Any character except
>                          %d59-126                ;  controls, SP, and
>                                                  ;  ":".
>
>   For the purposes of this specification, any optional field is
>   uninterpreted.

This is misleading, because it has to cover all new header fields
introduced by extensions and these will be, in general, structured. For
example, does the use of <unstructured> here imply that RFC 2047 may be
used freely on any header field not defined by this document - clearly
2047 was not intended to imply that, but it would not be hard to read it
that way. Better to invent some new term <foobar> with the same syntax as
<unstructured>, and then to say in that last sentence that any internal
structure of a <foobar> has to be defined elsewhere.

>4.  Obsolete Syntax
>
>   Earlier versions of this specification allowed for different (usually
>   more liberal) syntax than is allowed in this version.  Also, there
>   have been syntactic elements used in messages on the Internet whose
>   interpretation have never been documented.  Though some of these
    ^^^^^^^^^^^^^^                                     ^^^^
    interpretations                             Eh? I thought none of them
                                                was to be generated.

>   syntactic forms MUST NOT be generated according to the grammar in
>   section 3, they MUST be accepted and parsed by a conformant receiver.

which begs the question "what is a 'receiver'?" See earlier discussion.

>   ....  This
>   allowed many complex forms that have proven difficult for some
>   implementations to parse.

Which sounds like a good reason for no longer requiring agents to parse
them :-( .

>4.1.  Miscellaneous obsolete tokens
>
>      Note: The "period" (or "full stop") character (".") in obs-phrase
>      is not a form that was allowed in earlier versions of this or any
>      other specification.  Period (nor any other character from
>      specials) was not allowed in phrase because it introduced a
>      parsing difficulty distinguishing between phrases and portions of
>      an addr-spec (see section 4.4).  It appears here because the
>      period character is currently used in many messages in the
>      display-name portion of addresses, especially for initials in
>      names, and therefore must be interpreted properly.  In the future,
>      period may appear in the regular syntax of phrase.

But this is not an "obsolete" construct. We discussed this around 12
months ago, and the consensus then was that it ought to be renamed as an
<extended-phrase>, and moved out of the Obsolete Syntax.

Observe also that threat that it might one day be promoted to the regular
syntax. Are we ready yet to implement that threat? Probably not, but its
day will surely come. But it needs to be said in a more conspicuous place,
not hidden away in a section with "obsolete" in its name.

Likewise for <obs-phrase-list), wich is only used in <obs-keywords>. But
do we really care whether or not you are allowed to write
    Keywords: Joe Q. Public ?
>
>
>obs-qp          =       "\" (%d0-127)
>
>obs-body        =       *((*LF *CR *(obs-text *LF *CR)) / CRLF)
>
>obs-text        =       %d0-9 / %d11-12 /       ; %d0-127 except CR and
>                        %d14-127                ;  LF
>
>obs-unstruct    =       *((*LF *CR *(obs-utext *LF *CR)) / FWS)
>
>obs-utext       =       %d0-8 / %d11-12 /       ; %d0-127 except CR, LF,
>                        %d14-31 / %d33-127      ; and white space

The syntax given for these obs-constructs includes also the syntax for
their regular counterparts, which makes it very hard work to discover
exactly where the difference lies because of the huge redundancy that is
introduced. For example, if you had written

   obs-qp        =       "\" %d0

nothing would have changed, but it would be immediately obvious what the
difference was. Most of the obs-syntax could be re-written in such a
non-redundant manner, though I grant you there are a few cases which would
be difficult.

>4.3.  Obsolete Date and Time
>
>   The syntax for the obsolete date format allows a 2 digit year in the
>   date field and allows for a list of alphabetic time zone
>   specifications that were used in earlier versions of this
>   specification.  It also permits comments and folding white space
>   between many of the tokens.
>
>  obs-day-of-week =       [CFWS] day-name [CFWS]
>
>  obs-year        =       [CFWS] 2*DIGIT [CFWS]
>
>  obs-day         =       [CFWS] 1*2DIGIT [CFWS]
>
>  obs-hour        =       [CFWS] 2DIGIT [CFWS]
>
>  obs-minute      =       [CFWS] 2DIGIT [CFWS]
>
>  obs-second      =       [CFWS] 2DIGIT [CFWS]
>
>  obs-zone        =       (( "+" / "-" ) [CFWS] 4DIGIT) /
                           ..............

This lot was particularly difficult to spot the differences. I believe
that in <obs-hour> the first [CFWS] is unnecessary, and the [CFWS] at the
end of <obs-second> might be better moved to the start of <obs-zone>,
since that reflects better the way FWS is treated in the regular syntax.

>4.4.  Obsolete Addressing
>
>   There are three primary differences in addressing.  First, mailbox
>   addresses were allowed to have a route portion before the addr-spec
>   when enclosed in "<" and ">".  The route is simply a comma-separated
>   list of domain names, each preceded by "@", and the list terminated
>   by a colon.  Second, CFWS were allowed between the period-separated
>   elements of local-part and domain (i.e., dot-atom was not used).  In
>   addition, local-part is allowed to contain quoted-string in addition
                         ^^                                  ^^^^^^^^^^^
                        was
>   to just atom.  Finally, ....
    ^^^^^^^^^^^^
    in lieu of any of those period-separated atoms

>5.  Security Considerations
>
>   Care needs to be taken when displaying messages on a terminal or
>   terminal emulator.  Powerful terminals may act on escape sequences
>   and other combinations of ASCII control characters with a variety of
>   consequences.  They can remap the keyboard or permit other
>   modifications to the terminal which could lead to denial of service
>   or even damaged data.  They can trigger (sometimes programmable)
>   answerback messages which can allow a message to cause commands to be
>   issued on the recipient's behalf.  They can also affect the operation
>   of terminal attached devices such as printers.  Message viewers may
>   wish to strip potentially dangerous terminal escape sequences from
>   the message prior to display.  However, other escape sequences appear
>   in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
>   [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
>   should not be stripped indiscriminately.

Eh? what "other escape sequences" do you have in mind? I am not aware of
any meaningful use of NO-WS-CTLs in any of those standards. OTOH, if that
list is correct, should RFC 2231 be added to it?

>   Many implementations use the "Bcc:" (blind carbon copy) field
>   described in section 3.6.3 to facilitate sending messages to
>   recipients without revealing the addresses of one or more of the
>   addressees to the other recipients.  Mishandling this use of "Bcc:"
>   may disclose confidential information which could eventually lead to
>   security problems through knowledge of even the existence of a
>   particular mail address.  For example, if using the first method
>   described in section 3.6.3, where the "Bcc:" line is removed from the
>   message, blind recipients have no explicit indication that they have
>   been sent a blind copy, except insofar as their address does not
>   appear in the message header section.  Because of this, one of the
>   blind addressees could potentially send a reply to all of the shown
>   recipients and accidentally reveal that the message went to the blind
>   recipient.  When the second method from section 3.6.3 is used, the
>   blind recipient's address appears in the "Bcc:" field of a separate
>   copy of the message.  If the "Bcc:" field sent contains all of the
>   blind addressees, all of the "Bcc:" recipients will be seen by each
>   "Bcc:" recipient.  Even if a separate message is sent to each "Bcc:"
>   recipient with only the individual's address, implementations still
>   need to be careful to process replies to the message as per section
>   3.6.3 so as not to accidentally reveal the blind recipient to other
>   recipients.

But how could such revelation be avoided? Surely, if a blind recipient
replies to any message, his identity will be given away by the From header
of the reply? I see nothing in 3.6.3 that helps with this problem.

>6.  IANA Considerations
>
>   This document has no actions for IANA.

Oh yes it does!

RFC 3864 requires IANA to maintain a registry of header fields within
Email, News and HTTP. Anybody who defines a header field is obliged to
provide a template for use in that registry.

In the case of RFC 2822, Graham Klyne wrote a set of templates in RFC
4021. But these all reference RFC 2822 as the relevant specification
document, and so will become outdated as soon as 2822bis appears. On top
of that, they are all (IMHO) unnecessarily verbose.

So you need to write a full set of revised templates in here. I suggest
you look at draft-ietf-usefor-usefor-12 for how we laid out those
templates for USEFOR (carefullly avoiding such verbosities :-) ).

>Appendix A.  Example messages
>
>   Messages are delimited in this section between lines of "----".  The
>   "----" lines are not part of the message itself.

That is indeed an excellent notation. The Bad News is that you have
nowhere used it :-( .
>

>Appendix A.1.2.  Different types of mailboxes
>
>   This message includes multiple addresses in the destination fields
>   and also uses several different forms of addresses.
>
>   From: "Joe Q. Public" <[email-masked]>
>   To: Mary Smith <[email-masked]>, [email-masked], Who? <[email-masked]>
>   Cc: <[email-masked]>, "Giant; \"Big\" Box" <[email-masked]>
>   Date: Tue, 1 Jul 2003 10:52:37 +0200
>   Message-ID: <[email-masked]>
>
>   Hi everyone.
>
>   Note that the display names for Joe Q. Public and Giant; "Big" Box
>   needed to be enclosed in double-quotes because the former contains
>   the period and the latter contains both semicolon and double-quote
>   characters (the double-quote characters appearing as quoted-pair
>   construct).  ...
    ^^^^^^^^^
    constructs
>
>Appendix A.1.3.  Group addresses
>
> From: Pete <[email-masked]>
> To: A Group:Chris Jones <[email-masked]>,[email-masked],John <[email-masked]>;
> Cc: Undisclosed recipients:;
> Date: Thu, 13 Feb 1969 23:32:54 -0330
> Message-ID: <[email-masked]>
>
> Testing.
>
>   In this message, the "To:" field has a single group recipient named A
                                                                       ^
                                                                       "
>   Group which contains 3 addresses, and a "Cc:" field with an empty
         ^
         "
>   group recipient named Undisclosed recipients.

Wouldn't it be better to show a Bcc: header for the "Undisclosed
recipients" example?

>Appendix A.4.  Messages with trace fields
>
>   As messages are sent through the transport system as described in
>   [I-D.klensin-rfc2821bis], trace fields are prepended to the message.
>   The following is an example of what those trace fields might look
>   like.  Note that there is some folding white space in the first one
                                   ^^^^^^^
                                   folded
>   since these lines can be long.

>Appendix A.5.  White space, comments, and other oddities
>
>   White space, including folding white space, and comments can be
>   inserted between many of the tokens of fields.  Taking the example
>   from A.1.3, white space and comments can be inserted into all of the
>   fields.
>
>From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
>To:A Group(Some people)
>     :Chris Jones <c@(Chris's host.)public.example>,
>         [email-masked],
>  John <[email-masked]> (my dear friend); (the end of the group)
>Cc:(Empty list)(start)Undisclosed recipients  :(nobody(that I know))  ;
>Date: Thu,
>      13
>        Feb
>          1969
>      23:32
>               -0330 (Newfoundland Time)
>Message-ID:              <[email-masked]>
>
>Testing.
>
>   The above example is aesthetically displeasing, but perfectly legal.

Though legal, you should point out that it contains things that are
deprecated by 3.3 and by 3.4.1, and that agents might well choke on them.

>7.  References
>
>7.2.  Informative References
>
>   [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
>              USENET messages", RFC 1036, December 1987.

RFC 1036 is not actually referenced anywhere in the document. Moreover, if
you DO have a need to reference it (please do :-) ) then you ought to
refer to draft-ietf-usefor-usefor-12 instead.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Wed, 15 Aug 2007 00:12:18 -0400
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>
CC: SMTP Interest Group <[email-masked]>, LEMONADE WG <[email-masked]>, IMAP extensions mailing list <[email-masked]>, EAI WG <[email-masked]>, POP3 extensions mailing list <[email-masked]>, USEFOR WG <[email-masked]>, SIMPLE WG <[email-masked]>
Subject: Re: Mailing List Last Call for 2822 update internet-draft
Sender: [email-masked]

The mailing list last call for the 2822 update is now over.

I believe we have mailing list consensus on the issues that have been
raised during the last call. After an updated draft is posted by Pete,
we'll be moving the draft forward to IETF last call.

	Tony

Tony Hansen wrote:
> There have been some comments on draft-resnick-2822upd-* but they have
> dwindled down to none.
> 
> This is a "formal" Mailing List Last Call on
> draft-resnick-2822upd-02.txt. The last call will last for two weeks
> time, ending on August 10, 2007.
> 
> The document will be discussed on the 822 mailing list,
> <[email-masked]>. Please send your comments there.