Subject: Re: draft-ietf-drums-msg-fmt and obs-date
From: Chris Newman <[email-masked]>
To: John Mani <[email-masked]>
Cc: [email-masked]
Date: Mon, 14 Dec 1998 16:01:30 -0800 (PST)

On Fri, 4 Dec 1998, John Mani wrote:
> As per draft-ietf-drums-msg-fmt,
> 
> Handling of 2-digit years in the Date fields is:
> 
> If a two digit year is encountered whose value
> is between 00 and 49, the year is interpreted by adding 2000, ending up
> with a value between 2000 and 2049. If a two digit year is encountered
> with a value between 50 and 99, or any three digit year is encountered,
> the year is interpreted by adding 1900.
> ---------
> 
> However, this does not follow the X/Open recommendation of using '68' as the
> rollover number.
> 
> From: http://www.UNIX-systems.org/version2/whatsnew/year2000.html
> 
> Define yy such that if century is not specified, then values in the range 
> [69-99] refer to years in the twentieth century (1969 to
> 1999 inclusive), and values in the range [00-68] refer to years in the 
> twenty-first century (2000 to 2068 inclusive).
> 
> Comments ?

Comments on working documents of the IETF DRUMS WG should be sent to the
mailing list for that WG.

The rollover date isn't very important as every MTA produced since RFC
1123 was published SHOULD be using 4-digit years.  Given how much of an
improvement the new msg-fmt draft is over RFC 822, I prefer no changes on
such a trivial matter this late in the cycle. 

		- Chris

Date: 12 Dec 1998 18:03:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: New Message-ID Note
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Jacob Palme)  wrote on 11.12.98 in <v04011703b296bffec6c3@[198.67.177.140]>:

> At 16.36 +0100 98-12-10, Pete Resnick wrote:
> > No, that's wrong. First of all, we're not going to talk about "mail
> > items" in someone's "mailbox"; those aren't terms used anywhere in
> > this document. Second, there may or not be any messages in the
> > Originator's "mailbox" when this decision is made, and the existence
> > of such may or may not indicate the need for a new message id. If I'm
> > forwarding a message with some edits in it, it might be a good idea
> > to use a new message-id, even if I preserve the originator and date
> > fields for the convenience of my recipient.
>
> A good example where you would need "Supersedes".

An example where you most certainly wouldn't want to use "Supersedes".

MfG Kai

Date: Fri, 11 Dec 1998 13:27:48 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: New Message-ID Note (Was: Message-ID persistence in gateways)
Sender: [email-masked]

At 16.36 +0100 98-12-10, Pete Resnick wrote:
> No, that's wrong. First of all, we're not going to talk about "mail
> items" in someone's "mailbox"; those aren't terms used anywhere in
> this document. Second, there may or not be any messages in the
> Originator's "mailbox" when this decision is made, and the existence
> of such may or may not indicate the need for a new message id. If I'm
> forwarding a message with some edits in it, it might be a good idea
> to use a new message-id, even if I preserve the originator and date
> fields for the convenience of my recipient.

A good example where you would need "Supersedes".
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Fri, 04 Dec 1998 15:08:58 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: draft-ietf-drums-msg-fmt and obs-date 
Sender: [email-masked]

>> However, this does not follow the X/Open recommendation of using '68' as the
>> rollover number.

The X.509 (digital certificates) standard uses "50", and I think other
ISOish things that were using UTCTime are as well.

I do not think that RFC 822 email that was sent between 1950 and 1968 is an
issue worth spending much time on.

--Paul Hoffman, Director
--Internet Mail Consortium

To: John Mani <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-drums-msg-fmt and obs-date 
From: [email-masked]
Date: Fri, 04 Dec 1998 17:36:05 -0500
Sender: [email-masked]

--==_Exmh_-1904562042P
Content-Type: text/plain; charset=us-ascii

On Fri, 04 Dec 1998 14:20:35 PST, you said:
> As per draft-ietf-drums-msg-fmt,
> 
> Handling of 2-digit years in the Date fields is:
> 
> If a two digit year is encountered whose value
> is between 00 and 49, the year is interpreted by adding 2000, ending up
> with a value between 2000 and 2049. If a two digit year is encountered
> with a value between 50 and 99, or any three digit year is encountered,
> the year is interpreted by adding 1900.
> ---------
> 
> However, this does not follow the X/Open recommendation of using '68' as the
> rollover number.
..
> Comments ?

Well.. there's more PC's and Mac's out there than Unix systems.
Was the 50 rollover chosen for any particular reason?  If there's
some other recommendation that encourages that, we should probably
choose the one that the most machines will be following.

Although one should note that it's probably not an issue, since
it will only cause problems after Jan 1,2000 for people who try
to handle an e-mail sent between Jan 1, 1950 and Jan 1, 1968,
or sent after Jan 1, 2050. I doubt that there are many extant
email messages that this will affect.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-1904562042P
Content-Type: application/pgp-signature

--==_Exmh_-1904562042P--

Date: Fri, 4 Dec 1998 14:20:35 -0800 (PST)
From: John Mani <[email-masked]>
Reply-To: John Mani <[email-masked]>
Subject: draft-ietf-drums-msg-fmt and obs-date
To: [email-masked]
Content-MD5: fXNq5+pjsO6ZYxrqHzOCVA==
Sender: [email-masked]

As per draft-ietf-drums-msg-fmt,

Handling of 2-digit years in the Date fields is:

If a two digit year is encountered whose value
is between 00 and 49, the year is interpreted by adding 2000, ending up
with a value between 2000 and 2049. If a two digit year is encountered
with a value between 50 and 99, or any three digit year is encountered,
the year is interpreted by adding 1900.
---------

However, this does not follow the X/Open recommendation of using '68' as the
rollover number.

From: http://www.UNIX-systems.org/version2/whatsnew/year2000.html

Define yy such that if century is not specified, then values in the range 
[69-99] refer to years in the twentieth century (1969 to
1999 inclusive), and values in the range [00-68] refer to years in the 
twenty-first century (2000 to 2068 inclusive).

Comments ?

-john

Date: Fri, 4 Dec 1998 06:54:48 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: Comments on draft-gellens-format-02.txt
Sender: [email-masked]

At 10:18 PM -0800 12/3/98, Dan Kohn wrote:
> A generating agent SHOULD conduct the following steps to convert
> paragraph text as described in Section 4.1 (which is the format in which
> most mail messages are authored) to text/plain; format=flowed:

What follows strikes me as a bit too much implementation advice.  And 
I definitely think it should not be a SHOULD.  There may be other, 
more appropriate algorithms, conditions, etc, not covered, and I 
don't want people to think the standard discourages them.

> B. For each paragraph (i.e., *998<textchar> CRLF),

Paragraphs can be much longer than 998.  But this raises an 
interesting point, which is that nobody better do f=f unwrapping in 
an MTA and then pass the unwrapped text back out via SMTP.

From: Dan Kohn <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Comments on draft-gellens-format-02.txt
Date: Thu, 3 Dec 1998 22:18:32 -0800 
Sender: [email-masked]

I think <ftp://ftp.ietf.org/internet-drafts/draft-gellens-format-02.txt>
is a good approach and I'm a big fan of getting this implemented.
However, I find a little of the writing unclear.  Here are some
suggested replacements for the text.  I don't believe they change the
technical content.

I would globally replace TEXT/PLAIN with Text/Plain or text/plain, as it
is not an acronym.  The latter is consistent with usage in RFC 2046, and
looks better.

In section 4, I suggest adding a sentence to the end of the of the
second paragraph, saying: "In this memo, text which fits this
description is defined as 'fixed.'"

In section 4.1, I suggest adding a sentence to the end of the of the
first paragraph, saying: "In this memo, text which fits this description
is defined as 'flowed.'"  In that same paragraph, I would change "The
display shifts to the next line, starting with the word which would not
fit on the previous line." to "That word is displayed at the left margin
of the next line."

I would also add a sentence to the end of the section, saying:

When the text format described in this section is stored on a file
system that supports MIME typing, the text/paragraph type defined in
Appendix A could be an appropriate description of the media type.
However, many mailers incorrectly treat unknown text subtypes as an
attachment, so text/paragraph SHOULD NOT be used for network
communications.  Instead, format=flowed SHOULD be used for those
purposes.

In the first paragraph of section 4.2, change "or forwarded" to "and
forwarded mail".

After the first paragraph of section 4.2, I would add this example:

Example:

>>>>>>This is a comment from the first message to show a 
>quoting example.
>>>>>This is a comment from the second message to show a 
>quoting example.
>>>>This is a comment from the third message to show a quoting example.
>>>This is a comment from the fourth message to show a quoting example.
>>This is a comment from the fifth message to show a quoting example.
>This is a comment from the sixth message to show a quoting example.
It can be confusing to assign attribution to lines 2 and 4 above.

After the second paragraph of section 4.2, I would add this example:

Example:

This is paragraph text that is
meant to be flowed across
several lines.
However, the sending mailer is
converting it to fixed text at
a width of 72
characters, which causes it to
look like this when shown on a
PDA with only
30 character lines.

I would change the fourth paragraph of section 5 to the following:

A value of Flowed indicates that any line which ends in exactly one
space MAY be treated as a "flowed" line. (As specified in [MIME-IMT],
all line breaks in messages of any MIME "text" subtype MUST be
represented by a CRLF. So, flowed lines are delimited with SP CRLF, as
shown in the ABNF in section 6 below.) A series of one or more such
flowed lines is considered a paragraph, and MAY be flowed (wrapped and
unwrapped) as appropriate on display and in the construction of new
messages (see section 5.1).

I would replace the second paragraph and two lists of section 5.1 with
something more formalized, such as:

A generating agent SHOULD conduct the following steps to convert
paragraph text as described in Section 4.1 (which is the format in which
most mail messages are authored) to text/plain; format=flowed:

A. Select the line wrap length (LWL), which SHOULD be less than 78 (and
preferably 66) characters in length, not counting the CRLF.
B. For each paragraph (i.e., *998<textchar> CRLF),
 1. If the paragraph contains "--" SP CRLF (i.e., Usenet sig lines),
skip the line and go to Step B for the next paragraph.
 2. For paragraphs that consist solely of SP CRLF, replace with CRLF and
go to step B for the next paragraph.
 3. For paragraphs that end <non-sp> SP CRLF, convert to <non-sp> CRLF.
 4. For each paragraph longer than the LWL, find the last 1*SP in the
line that is less than the LWL.
  a. Convert this 1*SP to a SP CRLF, except in the following cases:
   (1). If the character after the 1*SP is a close angle-bracket (">"),
the 1*SP to the left of the previously selected 1*SP should instead be
converted into SP CRLF.  (Otherwise, for receivers that do not
understand format=flowed, it would be ambiguous whether the ">"
indicated quoting or not.)
   (2). If the characters after the 1*SP are "From ", the 1*SP to the
left of the previously selected 1*SP should instead be converted into SP
CRLF.  (This is necessary because some systems incorrectly alter lines
that begin with "From ".)
   (3) If the line consists of a single word longer than the LWL, the
agent MAY either add a CRLF at the LWL to wrap the line or use
quoted-printable encoding to "protect" the long line or leave the line
as is.  As noted below, if quoted-printable encoding is used, it SHOULD
NOT be used to protect the trailing space.
  b.  Reapply Step 4 to the remainder of the paragraph (the part after
the SP CRLF).
 5. Apply Step B to the next line.

[Note that the 1*SP in Step 3 allows lines that end 2*SP CRLF to be
treated as fixed, as per the ABNF (i.e., only SP CRLF indicates a flowed
line).  Is this really necessary?  I normally put two spaces between
sentences.  If the rule were changed to indicate that 1*SP CRLF
indicates a flowed line, then Step 4 could be changed from its current
effect, which is to convert double spaces at the end of a line to single
spaces.  I can't think of any practical cases where a user would need to
preserve the spaces count at the end of a paragraph.  By contrast, the
current formulation of Step 4 can result in losing spaces when the
*middle* of a paragraph falls at the end of a line, where there could be
an effect both on sentence spacing and on table columns separated by
spaces.  If you agree that flowed lines should be indicated by 1*SP CRLF
(as I do), the following rules would be changed:

 2. For paragraphs that end 1*SP CRLF, convert to CRLF.
 (3 can be deleted.)
 (Convert all occurrences of 1*SP in Step 4 and sub-steps to SP.)]

A receiving agent SHOULD conduct the following steps to convert
text/plain; format=flowed to paragraph text.

A. For each line,
 1. If the line contains "--" SP CRLF (i.e., Usenet sig lines) skip the
line and go to Step A for the next line.
 2. Convert <non-sp> SP CRLF into <non-sp> SP.
 3. Apply Step A to the next line.

[If flowed lines are instead indicated by 1*SP CRLF, line 2 would be
changed to: "Convert SP CRLF into SP."]

In section 5.3, it's not clear to me why it matters that some systems
insert ">" after "From ".  What negative effect is being avoided by
using ">" SP as the quote indicator?

"Flowed lines which are also quoted may require special handling on
display and when copied to new messages." should be changed to "Flowed
lines which are also quoted SHOULD be given special handling on display
and when copied to new messages."

In the fourth paragraph, "logical entity" should be replaced with
"paragraph".

The rest of 5.3 needs to be cleaned up a little more.  For instance, if
the rules are followed, an agent can't generate the ambiguous situation
you describe, right?  I think this description would be enhanced with
updated rules as above.  These rules would seem to be for a slightly
different situation, since the generating agent should be reflowing
quoted blocks and adding one level of depth in preparing the reply for
user editing.  If people think it would be useful, I will try to put
quoting rules together in the next couple days.

In section 6, you want to say:

The constructs used in a "text/plain; format=flowed" MIME body part are
described using [ABNF]:

body-part	= *paragraph *998textchar
textchar	= %x01-09 / %x0B-0C / %x0E-7F ; any 7-bit character
except null, CR, and LF

I admit the *998textchar is a little baroque, but otherwise we forbid
text body parts that don't end with a CRLF.  There doesn't seem any
reason to exclude that case, which is of course completely legal in
MIME.  And to disallow the use of CR and LF in lines as required for
text subtypes, you need to replace occurrences of CHAR with <textchar>
in your ABNF rules.

Also, to be compatible with the text subtype, I believe

	non-sp = %x01-19 / %21-7F ; any 7-bit except null or SP

(which also has 19 instead of 1F and %21 instead of %x21) should be
changed to

	non-sp = %x01-09 / %x0B-0C / %x0E-1F / %x21-7F ; any 7-bit
character except null, CR, LF, and SP

I believe you also need to add two extra section:

9. IANA Considerations

IANA is requested to add a reference to this RFC in the text/plain
registration and to register text/paragraph as described in Appendix A.

10.  Internationalization Considerations

The line wrap and quoting specifications of format=flowed may not be
suitable for certain charsets, such as for Arabic and Hebrew characters
that read from right to left.  Care should be taken in applying
format=flowed in these cases, and format=fixed combined with
quoted-printable encoding may be more suitable.

Suggested text for Appendix A:

1. Overview of text/paragraph

The "text/plain; format=flowed" MIME type described above SHOULD be used
to transmit paragraph text (defined in section 4.1) across networks in
order to maximize interoperability.

However, MIME media types are gaining increasing use in other contexts,
such as file systems, where converting paragraph text to format=flowed
may be less appropriate.  For those situations, this appendix specifies
an additional text subtype, text/paragraph.  This MIME type SHOULD NOT
be used for network communications such as [SMTP] (where many mailers
incorrectly treat unknown text subtypes as attachments) and [HTTP]
(where many browsers display paragraphs as long lines with a horizontal
scroll bar rather than wrapping them).  text/paragraph SHOULD only be
used in cases where it will cause no harm or user discomfort.  If there
is uncertainty as to the right approach, use format=flowed.

2. The text/paragraph Media Type

     MIME media type name: text

     MIME subtype name: paragraph

     Required parameters: none

     Optional parameters: charset

     Encoding considerations:

     As the text/paragraph media type is not generally expected to be
used across networks, only identity encoding (i.e., no transformations)
should be necessary.  Thus 7-bit (for 7-bit safe charsets and paragraphs
of under 999 characters), 8-bit (for non-7-bit safe 7-bit safe charsets
and paragraphs of under 999 characters), or binary (for everything else)
will normally be used.

     Security considerations:

     This media type has the same security considerations as text/plain.

     Interoperability considerations:

     text/paragraph has serious interoperability problems for most
protocols used to transfer MIME body parts.  With SMTP, many mailers
incorrectly treat unknown text subtypes as attachments, obscuring the
message.  With HTTP, many browsers display paragraphs as long lines with
a horizontal scroll bar rather than wrapping them.  Therefore,
text/paragraph SHOULD NOT be used for network communications.  Instead,
the generating agent SHOULD convert the text/paragraph content into
text/plain; format=flowed as described in Section 5.1 above.  This will
allow seamless conversion back into text/paragraph by the receiving
agent if so desired.

     Published specification: this document.

     Additional information:

     Magic Number(s): none

     File extension(s):
       No clear distinction is made between text/plain and
text/paragraph
       for file extensions.  The ".txt" extension is used for both (this
       internet draft is text/plain).  The ".asc" or ".ascii" extension
is
       traditionally used for text/plain with the US-ASCII character
set.  However, some applications have two text options, "Text Only
(*.txt)" (which corresponds to text/paragraph) and "Text Only with Line
Breaks (*.txt)" (which corresponds to text/plain; format=fixed).

     Macintosh File Type Code(s): TEXT
       NOTE: the TEXT file type on MacOS is used for both text/paragraph
       and text/plain; format=fixed.  The system application
"SimpleText" generates
       a text/paragraph file with type TEXT (which also may contain
       MacOS-specific out-of-band markup in the resource fork).  Text
       editors such as those that come with compilers use text/plain;
format=fixed.

     Intended usage: LIMITED USE

If you use this Appendix, you should credit Chris Newman and Ned Freed
for part of the text.  And, RFC 2068 needs to be referenced as [HTTP].