headers
Al Costanzo | 9 Sep 2000 11:25
Favicon

New I-D Transfer Encoding for MIME

9/9/1998

Greetings to all,

I am Al Costanzo one of the co-authors of RFC 1505.  Some may remember that
in the past I opposed MIME placement on standards track.

Five years later, MIME is widely deployed, I may have been wrong :-).

I am willing to admit to everyone that I was quite pig-headed back then
(maybe still am in some areas but I am working on it!).  A number of IETF
members contacted us ( the authors of RFC1505 ) and 'suggested' we redefine
a few RFC1505 items for MIME.

I for one refused the request, consulted the other co-authors and basically
did nothing in this area since the RFC was release in 1993.

Consider the above an apology for being pig-headed and not listening.

The first two Internet drafts I submitted are the beginning of this work.

* draft-costanzo-lzju90-mime-01.txt -

is a document that redefines LZJU90 as a new transfer encoding for MIME.
This transfer encoding also contains compression. This is an item that was
requested in 1993.

This is the second public iteration of the document.

LZJU90 is in the true public domain, there is no patent on it. A patent
(Continue reading)

Permalink | Reply | 11 comments |
headers
Al Costanzo | 10 Sep 2000 02:02
Favicon

Re: New I-D Transfer Encoding for MIME


Hello Harald,

>>
>.....which brings us straight back to the MAILCAP debate about how to get
>more info about a mail recipient than his address.
>I remember a BOF that I was just skimming past on this subject in Chicago;
>care to give us a capsule summary?
>
>(IMHO, a working mailcap has the potential to dramatically change the
>playing field of the email world wrt deployment of new features; can that
>be part of why it's so slow to get anywhere....?)
>
>                    Harald

I starting to feel like I'm missing the point. Why is this needed for
LZJU90?

I see no need....

-Al
Permalink | Reply | 5 comments |
headers
Charles Lindsey | 6 Sep 2000 11:07
Picon
Picon

Folding and whitespace in Mime parameters

The various Mime RFCs make regular use of parameters in the form
	...; attribute=value
where attribute is a token and value is a token or a quoted-string.

That is a nice tidy system, leaving room for extra parameters to be added
as extensions, and we are adapting it for use in the forthcoming RFC1036
update.

This means we need to specify a precise syntax, including [CFWS] in the
proper places, since we are following the style of the DRUMS revision of
RFC822. So the question arises as to where comments, folding and
whitespace are allowed (which is not easy to discover from the Mime
standards).

My understanding is that the full syntax should be:
	...[CFWS];[CFWS]attribute[CFWS]=[CFWS]value[CFWS]
and I base that on the assumption that a token is an atom, and can
therefore have [CFWS] either side of it. Certainly quoted-string can have
[CFWS] either side according to DRUMS.

Is that correct? If not, why not?

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl <at> clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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
Permalink | Reply | 4 comments |
headers
Paul Hoffman / IMC | 6 Sep 2000 18:39
Picon

Re: Folding and whitespace in Mime parameters

At 9:07 AM +0000 9/6/00, Charles Lindsey wrote:
>My understanding is that the full syntax should be:
>	...[CFWS];[CFWS]attribute[CFWS]=[CFWS]value[CFWS]
>and I base that on the assumption that a token is an atom, and can
>therefore have [CFWS] either side of it. Certainly quoted-string can have
>[CFWS] either side according to DRUMS.
>
>Is that correct? If not, why not?

It may be technically correct, but I propose that years of 
interoperability testing have shown that comments cause problems. Are 
the possible small value of comments worth the hassle? If you are 
starting from scratch, you might consider substituting [FWS] for 
[CFWS] everywhere above.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 3 comments |
headers
Charles Lindsey | 7 Sep 2000 13:00
Picon
Picon

Re: Folding and whitespace in Mime parameters

In <p0500160fb5dc2334e8f0 <at> [165.227.249.17]> Paul Hoffman / IMC <phoffman <at> imc.org> writes:

>At 9:07 AM +0000 9/6/00, Charles Lindsey wrote:
>>My understanding is that the full syntax should be:
>>	...[CFWS];[CFWS]attribute[CFWS]=[CFWS]value[CFWS]
>>and I base that on the assumption that a token is an atom, and can
>>therefore have [CFWS] either side of it. Certainly quoted-string can have
>>[CFWS] either side according to DRUMS.
>>
>>Is that correct? If not, why not?

>It may be technically correct, but I propose that years of 
>interoperability testing have shown that comments cause problems. Are 
>the possible small value of comments worth the hassle? If you are 
>starting from scratch, you might consider substituting [FWS] for 
>[CFWS] everywhere above.

I agree they would be ugly on either side of the '=', but they might be
sensibly placed before or after the whole parameter.

>From a USEFOR POV, we would want to write our syntax so as to allow
advantage to be taken of existing software written into agents that do
both mail and news. So I don't think we can forbid anything that is
allowed in mail, or mandate anything that is not allowed in mail.

Now if the MIME Gurus were to publicly state on this list that the intent
of the MIME specs was to restrict CFWS in some way, and that they would be
advocating such restrictions in the next MIME standard, then we would have
something to take note of. Essentially, we want to write a syntax that
will be consistent with best MIME practice, and we would happily remove
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Moore | 7 Sep 2000 15:38
Picon

Re: Folding and whitespace in Mime parameters

my opinion is that if you have to deal with comments at all, it's much 
better to allow comments between any two lexemes, rather than to 
invent complicated rules that say where the comments can and cannot go.
then you can write a generalized lexical analyzer that removes comments.

Keith
Permalink | Reply | 1 comment |
headers
Charles Lindsey | 8 Sep 2000 11:03
Picon
Picon

Re: Folding and whitespace in Mime parameters

In <200009071338.JAA18339 <at> astro.cs.utk.edu> Keith Moore <moore <at> cs.utk.edu> writes:

>my opinion is that if you have to deal with comments at all, it's much 
>better to allow comments between any two lexemes, rather than to 
>invent complicated rules that say where the comments can and cannot go.
>then you can write a generalized lexical analyzer that removes comments.

Well that is essentially what has always been done with mail. But you need
to define exactly what constitutes a lexeme.

But DRUMS now do it with a complicated grammar, the intention of which is
to match the effect of the "between lexemes" rule - which it more or less
does. The grammar is ugly, but that is pretty much inevitable given the
properties of grammars.

But either way results in what I quoted:

 [CFWS] ; [CFWS] token [CFWS] = [CFWS] token-or-quoted-string [CFWS]

since tokens and quoted strings are surely lexemes. Unless anybody thinks
otherwise (I agree it allows far too much, but that is what the rules seem
to imply).

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl <at> clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 13 Sep 2000 16:20

Question about MDN-request

 From RFC 2298:

      Disposition-Notification-Options =
           "Disposition-Notification-Options" ":"
           disposition-notification-parameters

      disposition-notification-parameters = parameter *(";" parameter)

      parameter = attribute "=" importance "," 1#value

      importance = "required" / "optional"

This syntax indicates that at least one parameter value is required?  I am 
considering a situation in which there is no meaningful value to attach to 
a disposition notification option, as the option itself simply acts as a 
flag to trigger some behaviour;  e.g. what I want to say is:

      Disposition-Notification-Options:
          Alternative-available=optional

Does anyone here know if the _requirement_ for a parameter value was a 
considered judgement or an oversight?  I don't have a meaningful value to 
include here.

(For more background to this question, see 
<draft-ietf-fax-content-negotiation-02.txt>, section 5.1.)

#g

------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane