Re: HARPOON Alternative

[Steve Thompson <[e-mail]>]

In message <"9625*/I=t/G=harald/S=alvestrand/OU=delab/O=sintef/PRMD=uninett/ADM
D= /C=no/"@MHS>  you write:

(bunch of stuff deleted)

>2 cases possible:
>
>1.1) You define a procedure for marking the body part that you produce with
>   what the original content-type was. Two subchoices:
>
>   1.1.1) The tagging is MIME compliant. We are back at HARPOON.
>
>   1.1.2) The tagging is not MIME compliant.
>
>   In both cases, this is a FOURTH variant of the HARPOON choice, where the
>   choice is not made on recipient capabilities, but on body part content.

Not what I had in mind.

>1.2) You throw away the typing information. In this case, the mapping is
>   not reversible, and the 3-body problem rears its head again.
>

Exactly what I had in mind.  See comments about 3 body problem below.

>> 2) Define a MIME/RFC-822 Header that will suppress the MIME->MHS
>>    conversion defined in the other drafts, and just deliver the whole
>>    thing as an IA5.  This is specifically for the recipient that
>>    wants MIME and will accept no substitute.  This is a philosophical
>>    change from HARPOON in that the responsibility for this decision
>>    has been moved from the gateway back to the originator.
>
>This means that you define a mapping of MIME -> X.400/88 that goes to
>IA5 only, that is, you do not attempt to use similar functionality in
>X.400/88 when gatewaying from MIME.
>If this is done, it belongs in the original MIMEMHS set, not in HARPOON.
>AND I think it is a wrong idea, since it breaks quite throughly in the
>context of a mailing list, or any other context where the capabilities
>of a *set* of recipients is not known at send time.

One of the key open issues with HARPOON is the capability of users to
receive modified contents when they don't have a UA that strips the
tags.  I'm trading that for the possibility of delivering a downgraded
package to a MIME capable reader, with a trap door to override the
downgrade.  For both cases, one could argue:  if you aren't sure about
the capability of your recipients, don't send MIME.

>
>> I think this works well for simple text-plus-binary-attachment type
>> messages.  ("Please find enclosed the Lotus Spreadsheet...").  Obviously,
>> the more sophisticated semantics (partials/alternatives/parallel) will
>> be lost, but at least the DATA gets through.  In that case, the "send
>> it as MIME in IA5" dropback can be exercised.
>> 
>
>I do not see how it works at all. Could you please explain to me what
>the message should look like on each link of the paths:
>
>MIME user -----> X.400/88 MTA -----> X.400/88 user
>                              -----> X.400/84 user
>                              -----> X.400/84 MTA  ----> MIME user
>

MIME user -> '88   : text/plain plus application/LOTUS
'88 MTA -> '88 User: IA5 plus EBP with Lotus OID
'88 MTA -> '84 User: IA5 plus BP14
'88 MTA -> '84 MTA:   "   "    "
'84 MTA -> MIME User: 
  Case 1: X.400 user attached to an '84 MTA, with a MIME capable reader.  
		  IA5 plus BP14.  They lose the Lotus tag.
  Case 2: SMTP User reached via RFC987.  They lose the whole BP 14.
		  This happens in HARPOON too, if the binary tag is used, right?

Is this what you mean by not working?  Please clarify.

Again, with HARPOON the non-MIME '84 recipient loses:  his contents get
modified.  Which is better?  Hard to say.  Since HARPOON is stuck, I
thought I'd float an alternative that doesn't need a UA modification.

To complete the 3 body problem analysis:  

HARPOON 

  '84 MIME  -> '84 MTA -> '88 MTA -> '88 User: OK
					   -> '88 NonHarpoon MTA -> '88 user: 
                                                Loses if can't process tags 
                       -> '88 MTA -> SMTP User via 1148/MIMEMHS: OK.
					   -> '88 NonHarpoon MTA -> '88 MTA: ????????
					   -> '84 User: Loses if can't process tag
                       -> SMTP via RFC987: Loses with binary encoding

  SMTP/MIME -> '88 MTA -> '88 user: OK
                       -> '84 user: Loses if can't process tag
					   -> '84 MTA -> MIME User: OK
					   -> '84 MTA -> RFC987 -> MIME User: 
								Loses if binary encoding used 

  '88 user  -> '88 MTA -> '84 User -> Loses if can't deal with tag
                       -> '84 MTA -> MIME User: OK 
					   -> '84 MTA -> RFC987 -> MIME: Loses binary BP
Alternative

  This case assumes the UA puts the whole MIME content in an IA5 BP.
  '84 MIME  -> '84 MTA -> '88 MTA -> '88 User: Loses, gets MIME mung.
                       -> '88 MTA -> SMTP User: OK (header munging?)
					   -> '84 User: Loses, gets MIME mung.
                       -> SMTP via RFC987 or RFC1327: OK (header munging?)

  SMTP/MIME -> '88 MTA -> '88 user: OK
                       -> '88 Non-MIMEMHS MTA -> '88 User: Loses, EBP Dropped
                       -> '84 user: gets downgraded tags
		 			   -> '84 MTA -> MIME User: Downgraded tags; use Trap door
		 			   -> '84 MTA -> RFC987 -> MIME User: Loses any binaries

  '88 user  -> '88 MTA -> '84 User: gets downgraded tags
                       -> '84 MTA -> MIME User: gets downgraded tags
                       -> '84 MTA -> RFC987 -> MIME: Loses binary BP

Ugh.  Neither of them are pretty.  Lots of "loses".  Lots more cases,
too.  (Various combinations of '84, '88, 987, 1327, MIMEMHS).

Let's leave the trees and look at the forest.

Harpoon's strength is dealing with the '84 origination/reception of MIME
for the MIME-capable '84 UA.  Its weakness is that it risks breaking
many other UAs in the process.  The alternative's strength is
interoperability to non-MIME '84 UAs.  Its weakness is requiring
encapsulation for MIME-capable '84 UAs.

Clear tradeoff between reversibility and interoperability.  This was one
of the many coups MIME itself accomplished; interoperability with
existing UAs without sacrificing function.  We would do well if we could
emulate it.

>More important, a gateway loses the possibility of reversing the
>transformation.

True.  The same trade off applies:  is it worth modifying the contents
*just in case* you encounter another gateway or UA downstream that knows
what to do with it?  At the risk of rendering the mail unreadable?

>
>One hundred percent agreement. But I think HARPOON is the *simplest*
>acceptable EBP downgrading standard, rather than an over-engineered one.
>The choices for EBP downgrading are:
>
>1. Lossy conversion (like RFC 1328, or CCITT)
>2. Lossless conversion
>   2.1 Lossless conversion to a private identification scheme
>   2.2 Lossless conversion to the MIME identification scheme.
>

It's important to distinguish between tag conversion and content
conversion.  I'm suggesting a third alternative, which is loss in the
tagging, but no loss in the contents (e.g. Lotus OID -> BP14, the
spreadsheet data gets through *without modification*).

If I understand HARPOON correctly, then if I get an EBP with the
ia5-text-body-part tag, I end up with an IA5 message *with a MIME tag
inside* instead of an unmodified IA5Text message.  Perhaps this is a
trivial case, but it demonstrates the difference in philosophy.

>SUMMARY:
>========
>
>- I think SJT's proposal (as far as I see it) will not work.
>  In particular, it fails when you consider the 3-body problem.

See comments above.  I think there are cases where it works better than
HARPOON and vice versa.  Please clarify if I've missed something.

>
>- I think HARPOON fulfils most of the valid points that SJT makes.
>
>QUESTION: Is it possible to reword HARPOON in such a way that this is
>clearer? Are there specific points in HARPOON where we could make things
>clearer?
>

I think so.  But, enough for now.

>Regards,
>
>                  Harald Tveit Alvestrand
>
>

sjt