Subject: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)
From: "Mikel Lindsaar" <[email-masked]>
To: [email-masked]
Date: Thu, 1 Nov 2007 12:35:39 +1100
List-Id: <ietf-822.imc.org>

Hello list,

This is my first post, so I apologise if this has already been
covered.  I searched through the full text archive file of ietf-822
(after going through the full itef-smtp archive file) and could not
find a concrete answer to my question.

I am improving/fixing bugs in a Email library for Ruby - I didn't
originally write the library, so I am being very careful in any
changes I make.

One situation I have is where a X-header field and Reply-To field has
a single piece of text that is longer than the 78 octet limit, but has
no white space break.

For example:

Reply-To: <[email-masked]>

The library currently folds this line as:

Reply-To:CRLF
LWSP<1234-1234-1234-1234...blah-with-no-further-fold

Now, I have two questions.

1) I believe that putting the CRLF immediately after the : in the
header field name is in violation of 2822 specifically that the header
line should contain the name, a colon, the field and terminated by a
CRLF.  Would this be a correct interpretation?

2) Irregardless of (1), what is the correct handling of a piece of
text in the field that is longer than 78 characters, but contains no
whitespace to fold?  ie, in unfolding, no whitespace can be inserted
back into the original text which would be destructive to the original
text.

I saw one mention of doing this:

Reply-To: <1234-1234-1234-1234-1234-12\CRLF
LWSP34-1234-1234-1234

But I can not find this in the RFC 2822 and my library breaks on this
when it tries to unfold, so I am not sure if my library's unfolding
function is at fault or if my folding implementation is incorrect.

If I have missed something obvious, I apologise.

Regards

Mikel

To: [email-masked]
Xref: clerew local.mime:5102
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Missing ABNF terms in 2821bis?
Date: Thu, 18 Oct 2007 15:00:37 GMT
Lines: 30
Sender: [email-masked]

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

>Right now, control characters are allowed in the following:

>- Domain literals on the right hand side of addresses

Well that's certainly one place they could and should go.

>- Quoted strings (which can be on the left hand size of addresses as 
>well as lots of other structured header fields)

And they are not really very clever there, given that allows them in
local-parts, which are a part of the addressing process.

>- Comments (which can appear in lots of structured header fields 
>including address fields)
>- Unstructured text (in fields and in the body)

But I don't care much either way about those two.

-- 
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]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Missing ABNF terms in 2821bis? (#1507)
Date:  Thu, 18 Oct 2007 10:01:47 +0200
Lines: 36
Cc: [email-masked]
Sender: [email-masked]

Pete Resnick wrote:

> I've copied this conversation over to ietf-822, since I think
> that will probably be where this issue is addressed.

Thanks, I replace the SMTP list by the EAI list, NO-WS-CTL also
affects an open issue #1507 with two drafts after a WGLC there.
In some way it is also related to I-D.klensin-net-utf8.

> Right now, control characters are allowed in the following:
=20
> - Domain literals on the right hand side of addresses
> - Quoted strings (which can be on the left hand size of
>   addresses as well as lots of other structured header fields)
> - Comments (which can appear in lots of structured header
>   fields including address fields)
> - Unstructured text (in fields and in the body)
=20
> Where are you proposing we should remove controls?

Wrt quoted strings used as local parts of addresses somebody
on the EAI list claimed that there was some legacy (ab)use of
BS to get visual effects with printed addresses.  I've never
seen this and can't confirm it, and I'd welcome when 2822upd
moves this "feature" to its "obs-cenities". =20

Ditto for comments, but that's not critical.  "Unstructured"
includes subjects, so maybe it's better to leave it alone (?)

For "domain literals" NO-WS-CTL has to be removed altogether,
don't bother to preserve it as "obs-cenity".  You could also
adopt the NetNews syntax for domain literals, or you could
adopt the more restrictive RFC 3986 "IPvFuture" syntax (in
addition to IPv4/IPv6 domain literals).

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Missing ABNF terms in 2821bis?
Date:  Thu, 18 Oct 2007 08:13:04 +0200
Lines: 21
Cc: [email-masked]
Sender: [email-masked]

[email-masked] wrote:

> Are there corresponding RFCs in the pipe that will allow actually
> doing an MX lookup of such beasts?

No, A, AAAA, and MX names follow the usual LDH-rules.  For UTF8SMTP
it's similar, IDNA and IDNAbis don't permit control codes.

The issue here are hypothetical "domain literals".  The "IPvFuture"
construct in RFC 3986 also doesn't permit control codes. =20

Of course you can lookup MX etc. records for names containing any
octet, but that would be no real SMTP MX.  RFC 4408 supports names
derived from local parts in its mechanisms (incl. mx, a, aaaa),
it doesn't allow control codes and dots in directly given labels.

That's admittedly one of the darker corners in the RFC 4408 syntax,
also discussed in <http://www.openspf.org/RFC_4408/Errata>. =20

 Frank

To: Pete Resnick <[email-masked]>
Cc: [email-masked], Frank Ellermann <[email-masked]>, ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
From: [email-masked]
Date: Wed, 17 Oct 2007 13:55:02 -0400
Sender: [email-masked]

--==_Exmh_1192643702_3070P
Content-Type: text/plain; charset=us-ascii

Argh.  Life of Brian.   My brains are tapioca this week - a close co-worker
passed away a few days ago and everything's still a big mess.... 

--==_Exmh_1192643702_3070P
Content-Type: application/pgp-signature

--==_Exmh_1192643702_3070P--

To: Pete Resnick <[email-masked]>
Cc: [email-masked], Frank Ellermann <[email-masked]>, ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
From: [email-masked]
Date: Wed, 17 Oct 2007 13:38:04 -0400
Sender: [email-masked]

--==_Exmh_1192642684_3070P
Content-Type: text/plain; charset=us-ascii

On Wed, 17 Oct 2007 09:46:35 PDT, Pete Resnick said:

> Right now, control characters are allowed in the following:
> 
> - Domain literals on the right hand side of addresses

Are there corresponding RFCs in the pipe that will allow actually doing an MX
lookup of such beasts?  Or ways to use them in a mailto: URI? Or all the *other*
myriad ways that people actually *expect* the right hand side of an address to
work? (Including the "internationalized domain names" effort now underway?)

Otherwise...

Judith: [on Stan's desire to be a mother] Here! I've got an idea: Suppose you
	agree that he can't actually have babies, not having a womb - which is
	nobody's fault, not even the Romans' - but that he can have the *right*
	 to have babies.
Francis: Good idea, Judith. We shall fight the oppressors for your right to
	have babies, brother... sister, sorry.
Reg: What's the *point*?
Francis: What?
Reg: What's the point of fighting for his right to have babies, when he can't
	have babies?
Francis: It is symbolic of our struggle against oppression.
Reg: It's symbolic of his struggle against reality. 

(Monty Python and the Holy Grail)

--==_Exmh_1192642684_3070P
Content-Type: application/pgp-signature

--==_Exmh_1192642684_3070P--

Date: Wed, 17 Oct 2007 09:46:35 -0700
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Missing ABNF terms in 2821bis?
Cc: Frank Ellermann <[email-masked]>, ietf-822 <[email-masked]>, [email-masked]
Sender: [email-masked]

I've copied this conversation over to ietf-822, since I think that 
will probably be where this issue is addressed.

On 10/17/07 at 6:51 AM -0700, [email-masked] wrote:

>>Peter J. Holzer wrote:
>>
>>>Which reminds me: What is the reason for allowing control 
>>>characters in email addresses?
>>
>>Idiocy.
>
>I try hard to stay out of these sorts of debates, but in this case I 
>am forced to agree. We are way past the point where backwards 
>compatibility is an acceptable excuse for something like this. It 
>should be obvious why  allowing nonprinting control characters in 
>addresses is a bad idea on many levels.
>
>And if common sense isn't enough here, how about the fact that it is 
>pretty clear that these things have obvious and severe 
>interoperability problems that will make it hard to meet the 
>criterua for draft standard?

Right now, control characters are allowed in the following:

- Domain literals on the right hand side of addresses
- Quoted strings (which can be on the left hand size of addresses as 
well as lots of other structured header fields)
- Comments (which can appear in lots of structured header fields 
including address fields)
- Unstructured text (in fields and in the body)

Where are you proposing we should remove controls?

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

Date: Tue, 16 Oct 2007 11:34:28 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
CC: ietf-822 mailing list <[email-masked]>, LEMONADE WG mailing list <[email-masked]>, IMAP extensions mailing list <[email-masked]>, EAI WG mailing list <[email-masked]>, POP3 extensions mailing list <[email-masked]>, USEFOR WG <[email-masked]>
Subject: Mailing List Last Call now open for draft-klensin-rfc2821bis-05.txt
Sender: [email-masked]

This is a "formal" Mailing List Last Call on
draft-klensin-rfc2821bis-05.txt. The last call will last for two weeks
time, ending on October 30, 2007.

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : Simple Mail Transfer Protocol
> 	Filename        : draft-klensin-rfc2821bis-05.txt
>...
> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-05.txt

If you go to http://tools.ietf.org/html/draft-klensin-rfc2821bis and
click on [Diff1], you'll see a highlighted list of changes between this
and the previous version.

Major changes for this release are indicated in Appendix G.7.

   G.7.  Changes from version -04 to -05
   1.  Added registry pointers to Section 8 (issue 36).
   2.  "for" clause in Received header reduced to a single mailbox,
       since this seems to reflect list consensus (issue 37).  An
       "additional registered clauses" entry was made to allow for
       future extension (also issue 37).
   3.  Corrected some I-D references to point to now-published RFCs.

At this point, all extant issues are considered closed.

The Mailing List Last Call is now declared open.

Depending on the outcome of the Mailing List Last Call, the next step
will be to submit the document (or its revision) to the IESG for
IETF-wide Last Call.

Thanks!

	Tony Hansen
	[email-masked]

To: [email-masked]
Xref: clerew local.mime:5098
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: New Version Notification for draft-resnick-2822upd-03
Date: Thu, 11 Oct 2007 20:02:33 GMT
Lines: 38
Sender: [email-masked]

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

>Notes:

>- There may be a couple of formatting issues. (I'm using a 
>non-released version of xml2rfc.) Those will be cleaned up before 
>release.

>- I've put in stronger language, though made no ABNF change, wrt 
>domain-literal/msg-id issues. Frank and Charles are the only people 
>on the list making comments about the issue at this point, and I'm 
>not convinced they've reached a satisfactory conclusion that goes 
>beyond the note I put in each section.

I'm 90% happy (particularly in the 3.4.1 language - I am not so sure that 
"the context in which they are used" really means much in in 3.6.4). And
Frank has a valid point regarding the horrors of NO-WS-CTL.

But 90% is still < 100% :-( .

Also, there remains the matter of the SP after the colon after the
header-name. Frank and I proposed some non-normative texts a week or so
back which AFAICS do no harm, but which warn of possible interoperability
problems and should encourage implementors to continue the current
convention of putting it there anyway.

But I welcome the many nit-fixes you have put in.

-- 
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]
From: "Steve Mills" <[email-masked]>
Subject: How long does approval take?
Date: Tue, 9 Oct 2007 19:40:50 -0500
Sender: [email-masked]

How long does it take for submitted MIME types to get approval once  
they've been submitted? It was in the application/vnd tree.

_________________________________________________________
Steve Mills                              Me: 952-401-6255
Senior Software Architect                         MultiAd
[email-masked]                       www.multi-ad.com

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: New Version Notification for draft-resnick-2822upd-03
Organization: The Eyrie
Date: Tue, 09 Oct 2007 16:34:30 -0700
Sender: [email-masked]

"Frank Ellermann" <[email-masked]> writes:
> Pete Resnick wrote:

>> no ABNF change, wrt domain-literal/msg-id issues. Frank and Charles
>> are the only people on the list making comments about the issue at
>> this point

> IIRC Russ and Alexey also prefer better compatibility with NetNews
> for the RHS of Message-IDs.

Yes, I still think that it would be a good idea to make changes here.  I'm
just not willing to keep reiterating my belief without adding anything
new, and I don't really have anything new to add.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: New Version Notification for draft-resnick-2822upd-03
Date:  Tue, 9 Oct 2007 14:39:49 +0200
Lines: 37
Sender: [email-masked]

Pete Resnick wrote:

> no ABNF change, wrt domain-literal/msg-id issues. Frank and Charles
> are the only people on the list making comments about the issue at
> this point

IIRC Russ and Alexey also prefer better compatibility with NetNews
for the RHS of Message-IDs.  If you feel that the NetNews concept of
a "canonical Message-ID" is not important enough for 2822upd there's
another way to solve it:

Just get rid of NO-WS-CTL in the definition of <dtext>.  Proposal:

| dtext           =3D %d33-90 /          ; Visible US-ASCII characters
|                   %d94-126           ; excluding "[", "]", or "\"

That also fixes the pollution of the <General-address-literal> in
2821bis, and it's nearer to <IPvFuture> in STD 66.  The <IPvFuture>
construct excludes more printable US-ASCII characters, not only [\],
also <>/?#@. =20

Control characters in domain literals just make no sense, especially
when we're talking about fictitious "General-address-literal" or
"IPvFuture" literals.  For real IPv4 and IPv6 literals it's already
settled that they don't contain control characters.

I don't think that you need an <obs-dtext> for this issue.  You could
just argue that the interoperability of control characters in domain
literals was questionable using NetNews / mail2news gateways / NNTP
as the evidence. =20

IIRC my experiments with NO-WS-CTL in domain literals of an SMTP EHLO
also showed that this "feature" isn't interoperable.  It doesn't work
with NNTP (by definition), it doesn't work with SMTP (in practice),
so let's please get rid of it.

 Frank

Date: Wed, 3 Oct 2007 17:20:45 -0500
To: ietf-822 <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Fwd: New Version Notification for draft-resnick-2822upd-03
Sender: [email-masked]

Notes:

- There may be a couple of formatting issues. (I'm using a 
non-released version of xml2rfc.) Those will be cleaned up before 
release.

- I've put in stronger language, though made no ABNF change, wrt 
domain-literal/msg-id issues. Frank and Charles are the only people 
on the list making comments about the issue at this point, and I'm 
not convinced they've reached a satisfactory conclusion that goes 
beyond the note I put in each section.

pr

--- begin forwarded text

Return-Path: <[email-masked]>
From: IETF I-D Submission Tool <[email-masked]>
Subject: New Version Notification for draft-resnick-2822upd-03
Date: Wed, 03 Oct 2007 17:36:39 -0400

A new version of I-D, draft-resnick-2822upd-03.txt has been 
successfuly submitted by Pete Resnick and posted to the IETF 
repository.

Filename:	 draft-resnick-2822upd
Revision:	 03
Title:		 Internet Message Format
Creation_date:	 2007-10-03
WG ID:		 Independent Submission
Number_of_pages: 57

Abstract:
This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the
framework of "electronic mail" messages.  This specification is a
revision of Request For Comments (RFC) 2822, which itself superseded
Request For Comments (RFC) 822, "Standard for the Format of ARPA
Internet Text Messages", updating it to reflect current practice and
incorporating incremental changes that were specified in other RFCs.

The IETF Secretariat.

--- end forwarded text

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

From: "Steve Mills" <[email-masked]>
Subject: Re: registering new MIME types for an application
Date: Wed, 3 Oct 2007 09:26:05 -0500
To: [email-masked]
Sender: [email-masked]

On Oct 2, 2007, at 18:07:15, Pete Resnick wrote:

> I don't see a reason to register the image type. It sounds like  
> your documents are in the same category as PDFs, which are  
> certainly an application sub-type. Register the application/ 
> vnd.multiad.creator and be done with it. :-)

Great! Thanks so much for responding.

_________________________________________________________
Steve Mills                              Me: 952-401-6255
Senior Software Architect                         MultiAd
[email-masked]                       www.multi-ad.com

Date: Tue, 2 Oct 2007 18:07:15 -0500
To: "Steve Mills" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: registering new MIME types for an application
Cc: [email-masked]
Sender: [email-masked]

On 10/2/07 at 8:56 AM -0500, Steve Mills wrote:

>MultiAd is our company name. Creator is the name of our software 
>application which creates and edits documents. The Creator file 
>format is proprietary. While Creator documents are of a graphical 
>nature, I don't feel they are "image" documents in the same vein 
>that the current list of image/* types are. But since they certainly 
>aren't audio or video, I guess image is the tree that fits best.
>
>I've read through RFC4288, but am still unsure if we should register 
>only the application/vnd.multiad.creator or both the appliation and 
>image types. I'm very new to this whole MIME type process (I'm a 
>developer, not an IT type person). Would you be able to suggest what 
>would be best, or explain why both might be required?

I don't see a reason to register the image type. It sounds like your 
documents are in the same category as PDFs, which are certainly an 
application sub-type. Register the application/vnd.multiad.creator 
and be done with it. :-)

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

To: [email-masked]
From: "Steve Mills" <[email-masked]>
Subject: registering new MIME types for an application
Date: Tue, 2 Oct 2007 08:56:09 -0500
Sender: [email-masked]

Sorry, I noticed an unfinished sentence below.

I'm not sure if this is the correct list for this (there are tons!),  
but it was suggested that I try this list. Here's my question:

We have recently been asked by one of our customers if we have  
registered MIME types for our application's documents. They said they  
needed MIME types because part of their process is web-based, and  
suggested we use the following assignments:

application/vnd.multiad.creator
image/vnd.multiad.creator

MultiAd is our company name. Creator is the name of our software  
application which creates and edits documents. The Creator file  
format is proprietary. While Creator documents are of a graphical  
nature, I don't feel they are "image" documents in the same vein that  
the current
<EDIT>
list of image/* types are. But since they certainly aren't audio or  
video, I guess image is the tree that fits best.
</EDIT>

I've read through RFC4288, but am still unsure if we should register  
only the application/vnd.multiad.creator or both the appliation and  
image types. I'm very new to this whole MIME type process (I'm a  
developer, not an IT type person). Would you be able to suggest what  
would be best, or explain why both might be required?

_________________________________________________________
Steve Mills                              Me: 952-401-6255
Senior Software Architect                         MultiAd
[email-masked]                       www.multi-ad.com

To: [email-masked]
From: "Steve Mills" <[email-masked]>
Subject: registering new MIME types for an application
Date: Tue, 2 Oct 2007 08:25:11 -0500
Sender: [email-masked]

I'm not sure if this is the correct list for this (there are tons!),  
but it was suggested that I try this list. Here's my question:

We have recently been asked by one of our customers if we have  
registered MIME types for our application's documents. They said they  
needed MIME types because part of their process is web-based, and  
suggested we use the following assignments:

application/vnd.multiad.creator
image/vnd.multiad.creator

MultiAd is our company name. Creator is the name of our software  
application which creates and edits documents. The Creator file  
format is proprietary. While Creator documents are of a graphical  
nature, I don't feel they are "image" documents in the same vein that  
the current

I've read through RFC4288, but am still unsure if we should register  
only the application/vnd.multiad.creator or both the appliation and  
image types. I'm very new to this whole MIME type process (I'm a  
developer, not an IT type person). Would you be able to suggest what  
would be best, or explain why both might be required?

_________________________________________________________
Steve Mills                              Me: 952-401-6255
Senior Software Architect                         MultiAd
[email-masked]                       www.multi-ad.com