headers
Tony Hansen | 15 Aug 06:12
Picon
Favicon

Re: Mailing List Last Call for 2822 update internet-draft

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,
> <ietf-822 <at> imc.org>. Please send your comments there.
Permalink | Reply | 0 comments |
headers
SM | 16 Aug 08:11

Re: Comments on draft-resnick-2822upd-02.txt


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

Permalink | Reply | 1 comment |
headers
Gary Welles | 16 Aug 22:39

Re: Comments on draft-resnick-2822upd-02.txt


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
Permalink | Reply | 0 comments |
headers
Pete Resnick | 17 Aug 06:13
Favicon

Re: Comments on draft-resnick-2822upd-02.txt


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

Permalink | Reply | 1 comment |
headers
Alan Barrett | 17 Aug 09:54

Re: Comments on draft-resnick-2822upd-02.txt


On Thu, 16 Aug 2007, ned+ietf-822 <at> mrochek.com 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)
Permalink | Reply | 1 comment |
headers
Charles Lindsey | 17 Aug 19:15
Picon
Picon

Re: Comments on draft-resnick-2822upd-02.txt


In <20070817075403.GT27645 <at> apb-laptoy.apb.alt.za> Alan Barrett <apb <at> cequrux.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 17 Aug 19:18
Picon
Picon

Re: Comments on draft-resnick-2822upd-02.txt


In <6.2.5.6.2.20070815214922.02a4df30 <at> resistor.net> SM <sm <at> resistor.net> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 17 Aug 22:44
Picon
Picon

Re: Comments on draft-resnick-2822upd-02.txt


In <01MK8ESGFC4M005BGY <at> mauve.mrochek.com> ned+ietf-822 <at> mrochek.com 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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 18 Aug 01:03
Picon
Picon

Re: Comments on draft-resnick-2822upd-02.txt


In <p0625011dc2e94f8089a2@[74.134.5.163]> Pete Resnick <presnick <at> qualcomm.com> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Crocker | 19 Aug 20:59

Re: Comments on draft-resnick-2822upd-02.txt


ned+ietf-822 <at> mrochek.com 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
(Continue reading)

Permalink | Reply | 6 comments |

Gmane