headers
Dan Kohn | 4 Dec 1998 07:18

Comments on draft-gellens-format-02.txt

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Dorner | 4 Dec 1998 13:54

Re: Comments on draft-gellens-format-02.txt

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.
Permalink | Reply | 0 comments |
headers
John Mani | 4 Dec 1998 23:20
Picon

draft-ietf-drums-msg-fmt and obs-date

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
Permalink | Reply | 3 comments |
headers
Valdis.Kletnieks | 4 Dec 1998 23:36
X-Face
Picon
Favicon

Re: draft-ietf-drums-msg-fmt and obs-date

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 5 Dec 1998 00:08
Picon

Re: draft-ietf-drums-msg-fmt and obs-date

>> 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
Permalink | Reply | 0 comments |
headers
Jacob Palme | 11 Dec 1998 13:27
Picon
Picon

Re: New Message-ID Note (Was: Message-ID persistence in gateways)

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 <jpalme <at> dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Permalink | Reply | 1 comment |
headers
Kai Henningsen | 12 Dec 1998 17:03
Picon

Re: New Message-ID Note

jpalme <at> dsv.su.se (Jacob Palme)  wrote on 11.12.98 in <v04011703b296bffec6c3 <at> [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
Permalink | Reply | 0 comments |
headers
Chris Newman | 15 Dec 1998 01:01

Re: draft-ietf-drums-msg-fmt and obs-date

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane