Re: A multiple bodypart multiple content type message

[Olle J{rnefors <ojarnef@xxxxxxxxxxxx>]

> From: Erik Naggum <erik@naggum.uu.no>
> Date: Mon, 18 Feb 1991 15:21:18 +0100
>
> > Timo's and Ned's original proposal, to use RFC934 as it is, has 
> > two disadvantages compared to my proposal:
> 
> > -1 In ordinary text many more lines has to be modified before 
> >    inclusion in a body part, since it is a common practice to 
> >    "underline" subheadings in a text with a line of '-'s.
>
> This would have been a problem if it were done by humans.

Multiple body part messages will have to be "parsed" by those 
humans that still have old UAs, which can't do that for them.  
They may also want to be able to construct such messages them-
selves, by the means of commonly used editors.  Therefore, the 
differences between the original text and the text after it has 
been included in a multiple body part message should be as small 
as possible.

> Also,
> I can't say that this underlining thing is anywhere near common.

My experience is that this is a common way to indicate an under-
lined heading.  (Other ways are with "="s and "*"s, preferably 
used for higher-level headings.)  This doesn't mean such under-
linings are common.  Mail messages tend to be short and usually 
doesn't have headings at all.  The important point, though, is 
that they are not as infrequent in ordinary text as lines start-
ing with a colon.

> > -2 RFC934 only permits parts with special encoding to be 
> >    included at *one* point in a text (because the end marker 
> >    need not in any way differ from the start marker).  With my 
> >    proposal it is possible to include e.g. graphically encoded 
> >    diagrams in several places in a long text.
> 
> I don't think your conclusion about the one point is valid from the
> premises.  In other words, I think your fabricating arguments.

There is no fabrication.  My conclusion follows directly from 
the following part of RFC934.

"Message Encapsulation

...

   2. The Text Portion

   The text of the draft forwarding message consists of three parts: an
   initial text section, the encapsulated messages, and the final text
   section.

      2.1. The Initial Text Section

      All text (if any) up to the first EB [encapsulation boundary]
      comprises the initial text
      section of the draft.  ...

      2.2. The Final Text Section

      All text (if any) after the last EB composes the final text
      section of the draft.  ...

      2.3. Encapsulated Messages

      Each encapsulated message is bounded by two EBs: a pre-EB, which
      occurs before the message; and, a post-EB, which occurs after the
      message.  For two adjacent encapsulated messages, the post-EB of
      the first message is also the pre-EB of the second message."

> > -3 A body part can only be inserted at the beginning of a line 
> >    in a text body.  My proposal makes it possible to put for 
> >    instance a little picture anywhere in a text line.
> 
> This is another non-problem.  Internet mail is line oriented.
> It's not octet-stream oriented like X.400.

The purpose of the multi-bodypart multi-content extension to 
RFC822 is to facilitate sending data of other types than simple 
text by mail.  I have suggested a way to remove the restriction 
that such data can only be inserted into text at the beginning/
end of lines.  This technique is perfectly compatible with the 
line-orientation of RFC822.  The data to be encoded obviously 
doesn't have to exhibit the same line-orientation as the (7-bit 
or 8-bit) text into which it is encoded.

> > -4 To be able to ascertain that a boundary marker has been 
> >    encountered you have to read (and remember) at least 25 
> >    characters.  In my proposal the first two characters on a 
> >    line decides if it is a boundary marker.  (The first charac-
> >    ter must be ':', the next '<', '-', or '>'.  The line must 
> >    be preceded by a blank line.)
> 
> I think it's computationally feasible to compare entire lines at
> once.  Again, I think you assume an octet stream view of the world.

I was talking about human readers with old UAs here, who have to 
recognize the boundary markers themselves.  They would have to 
know which of the variants
------- End-Of-Encapsulated-Bodypart
------- End Of Encapsulated Body Part
------- End Of Encapsulated Bodypart
------- End of Encapsulated Bodypart
-------  End of Encapsulated Bodypart
etc. is the only TRUE boundary marker.  (All others are only 
ordinary text.)  But I admit this is a minor point.

> > -5 Timo's markers are written in English.  Why favour one of 
> >    all natural languages on the earth?
> 
> Come on!  Want all the header fields to be in Swahili with an SMTP
> option?  Feeping creaturism, if you ask me.

My point is that it is unnecessary in this case to introduce 
even more "English-biased" syntax.  (And if we could redesign 
RFC822 from scratch, header field names should have a more 
compact, language-independent coding.)

--
Olle Jarnefors, Royal Institute of Technology, Stockholm <ojarnef@admin.kth.se>