ietf-822
[Top] [All Lists]

[no subject]

1991-04-09 12:36:41
ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)EDU Subject: Re: text --> IA5 ?  
In-reply-to:
Your message of Tue, 09 Apr 91 14: 40:55 -0500.
             
<671222455(_dot_)282521(_dot_)KLENSIN(_at_)INFOODS(_dot_)MIT(_dot_)EDU> 
Reply-to: Stef(_at_)ics(_dot_)uci(_dot_)edu
From: Einar Stefferud <Stef(_at_)ics(_dot_)uci(_dot_)edu>
Date: Tue, 09 Apr 91 12:33:44 MDT
Message-ID: <10179(_dot_)671225624(_at_)nma(_dot_)com>
Sender: stef(_at_)nma(_dot_)com

Thanks John -- I think the right place to draw the line is at the
concept of identifiable whole body parts, with perhaps a little
extension to indicate the existance of some potential concurrency
among some body-parts, but no requirement that the indication of
concurency must result in concrrent action on the part of any UA.
(Per some comments from Nathaniel a while back.)

I expect that we should not exceed the capabilities of X.400 in this
regard, for any linkage among the body-parts carried in an IPM
envelope.  Lets not exceed X.400 in this reard.

I believe that anything more complext than this should be part of a
separate standard for structured multi-media objects that are entirely
independent of mail, so they may be transported in any way that is
interesting and available.

        FTP, TAPE, DISKETTES, BAR-CODES, whatever..

To me, multi-media mail is just a tool for carrying multiple objects
of arbitrary kinds.  I do not want to limit the kinds in any way,
though I understand fully that we need standards so that composers can
expect recipients to be able to understand what composers compose.

So, I want to shunt this complecity to the multi-media object
developemnt track.

Best...\Stef

<Prev in Thread] Current Thread [Next in Thread>
  • [no subject],  <=