Subject: [lemonade] Life on the List, and Vienna

From: "Eric Burger" <[email-masked]>
Date: Thu, 5 Jun 2003 22:12:55 -0400

Now that things are moving again, do we want to meet in Vienna?

I would envision more of a working session than a presentation session.  E.g., sharpen your pencils, styli, and notebooks.

Please RSVP to me *directly* by Monday.  I would like to take a count to find out (1) if we have critical mass and (2) how small a room to book.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Dave Crocker <[email-masked]>
Date: Sun, 8 Jun 2003 15:02:57 -0700

Eric,

EB> Now that things are moving again, do we want to meet in Vienna?

EB> I would envision more of a working session than a presentation
EB> session.  E.g., sharpen your pencils, styli, and notebooks.

The question is what we will discuss.  So we should simply offer items
to discuss (and, yes, discuss, not present.)

I'll be in Vienna.  Don't have items to suggest at the moment.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Mon, 9 Jun 2003 11:01:40 -0700

Hello Eric,

Of course, this is a good idea.  I'll be there.

I agree with the idea of discussing changes or innovations.  I'll contribute
my $0.02 to the discussion:

Based on innovative use of IMAP for mobile messaging that we have
participated in, with different mobile operators, I'd suggest that the
essential requirements for mobile messaging consist of the following:

a1. Efficient, Binary Transport of Multimedia Message Components

    An efficient, access protocol that allows partial or complete access,
    with efficient transport of binary data, to multimedia message and
    information about it (content-type, MIME structure, etc.).

    The retrieval of meta-data should be made as efficient as possible, and
    also allow the client to control how much information is returned for
    any given request.

A2. Additional, External Content Processing for Accessed Messages

    The access protocol must support a mechanism to allow some messaging
    clients to be able to request additional processing on one or more
    components of the original multimedia content. Examples of additional
    processing include: image size and format transformations, audio codec
    transcoding, text-to-speech, and speech-to-text, etc.

b1. Efficient, Binary Messaging Submission

    A message submission protocol that supports efficient binary transport.

b2. External References

    The Messaging Submission protocol must support an external reference
    mechanism by which multiple components can be assembled into a
    multimedia message.

    The reference mechanism must allow for references to messages, or
    components of messages, obtained from [a], must be transparent to the
    eventual recipients(s), and must not depend upon or require
    authentication agreements between the originator and recipient(s).

These four requirements, two for access and two for submission, are the
essence of the kinds of innovative adaptations made by mobile operators in
achieving a viable multimedia mobile messaging service.

If you read these requirements carefully, you'll notice that it is *not* a
foregone conclusion that IMAP (which fulfills [a1] easily) should be adapted
to fulfill either [b1] or [b2].

I think IMAP4, with BINARY, WINDOW, & SORT features, supports [a1]

IMAP4 CHANNEL supports [a2]

SMTP with BDAT supports [a3]

And, IMHO, the Path of Least Resistance would be to introduce a new SMTP
command, say, ATTACH, by which the contents addressed by a URL would be
inserted, as an additional MIME object, into the outgoing message.

The issue of whether or not the ATTACH URL were authenticated or not depends
upon the scheme referenced in the URL.

-- 
Best regards,
 Alan K. Stebbens <[email-masked]>
 Principal Product Technologist, Messaging
 Openwave Systems, Inc.
 Cell: +1.805.886.8886  Voice/Fax: +1.866.579.0801
 Desk: +1.805.884.3162
 YIM/MSN: alan_stebbens  ICQ: 51361674  AIM: akstebbens

---

From: [email-masked]
Date: Mon, 9 Jun 2003 11:12:14 -0700

Hi Alan,
	In both A1 and B1, you have Efficient, Binary as
pair of linked needs.  Are they linked because you see
"binary" as the only way to achieve "efficient"?  If
not, is there a different need for this requirement for binary
transport?
			regards,
				Ted Hardie

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Mon, 9 Jun 2003 11:34:13 -0700

hqc> In both A1 and B1, you have Efficient, Binary as pair of linked needs.
hqc> Are they linked because you see "binary" as the only way to achieve
hqc> "efficient"? If not, is there a different need for this requirement for
hqc> binary transport?

Hello Ted,

Efficient is needed to minimize the over-the-air byte count, which is the
basis for mobile operator billing to subscribers

Binary is needed to transport multimedia objects, such as audio files,
pictures, and even video files.

In theory, both are independent requirements, but with both being important,
they often end up being linked in practice.

--
Best regards,
Alan K. Stebbens

>>upon the scheme referenced in the URL.

hqc> _______________________________________________
hqc> lemonade mailing list
hqc> [email-masked]
hqc> https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Nathaniel Borenstein <[email-masked]>
Date: 09 Jun 2003 15:35:22 -0400

> inserted, as an additional MIME object, into the outgoing message.

Pardon me if I'm coming into this discussion a bit late, but couldn't
you accomplish the same thing by defining this as the default behavior
of a mobile messaging gateway that encounters a MIME type of
message/external-body?  I'm not clear why you can't use that existing
MIME type.  -- Nathaniel

---

From: "Jonathan T. Hawkins" <[email-masked]>
Date: Mon, 09 Jun 2003 12:40:38 -0700

At the moment, the embedded URLs are pulled together via the MUA, the IMAP
client.  The proposal is for SMTP MTA side composition.

Jonathan

---

From: Randall Gellens <[email-masked]>
Date: Mon, 9 Jun 2003 16:12:19 -0400

>  client.  The proposal is for SMTP MTA side composition.

I think the suggestion is to use message/external-body instead of 
URLs.  This has been discussed before, since it provides a clear way 
to distinguish between references which are to be expanded and those 
which should remain as-is.

>  Content-type: text/x-vcard; charset=us-ascii; name=jonathan.hawkins.vcf
>  Content-disposition: attachment; filename=jonathan.hawkins.vcf
>  Content-description: Card for Jonathan T. Hawkins
>  Content-Transfer-Encoding: 7BIT
>
>  Attachment converted: TiLand:jonathan.hawkins 6.vcf (TEXT/R*ch) (0005D7CC)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Beware of false knowledge; it is more dangerous than ignorance.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Mon, 9 Jun 2003 14:10:00 -0700 (Pacific Daylight Time)

> which should remain as-is.

I don't think that "instead" is correct.

As I understood it, MESSAGE/EXTERNAL-BODY would be used as the means in
MIME by which the IMAP access cookie (which we're assuming will be an IMAP
URL) would be conveyed.  I'm surprised that there isn't a URL access-type
defined already; but that is easy to amend.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 09 Jun 2003 17:31:48 -0400

Hi Mark,

--On Monday, June 9, 2003 2:10 PM -0700 Mark Crispin 
<[email-masked]> wrote:

| As I understood it, MESSAGE/EXTERNAL-BODY would be used as the means in
| MIME by which the IMAP access cookie (which we're assuming will be an IMAP
| URL) would be conveyed.  I'm surprised that there isn't a URL access-type
| defined already; but that is easy to amend.

There is:

RFC2017: 'Definition of the URL MIME External-Body Access-Type'.

-- 
Cyrus Daboo

---

From: Doug Royer <[email-masked]>
Date: Mon, 09 Jun 2003 15:44:00 -0600

> client.  The proposal is for SMTP MTA side composition.

How is that different than having the gateway do the message/external-body
processing? If the CELL-MUA generates a MIME message that contains an
external body part. Then the CELL-MUA's MTA (is gateway) ~could~ be written
so that it expands/replaces the external body part into the message that
is sent.

And if there is going to be MTA side processing of messages, then
if done my MIME type or URL should make no difference with respect
to security.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: "Alan K. Stebbens" <[email-masked]>
Date: Mon, 9 Jun 2003 15:12:14 -0700

>> which should remain as-is.

MC> I don't think that "instead" is correct.

MC> As I understood it, MESSAGE/EXTERNAL-BODY would be used as the means in
MC> MIME by which the IMAP access cookie (which we're assuming will be an IMAP
MC> URL) would be conveyed.  I'm surprised that there isn't a URL access-type
MC> defined already; but that is easy to amend.

The problem is not a specific type/subtype, but what the SMTP server does
with it.

Currently, most SMTP servers do not interpolate (dereference) embedded
links; they just pass them along.

The problem with the current functionality is that the implicit,
network-based authentication enjoyed by an MTA that is a "companion" to an
IMAP server, is not likely to be available to the destination SMTP server
which ultimately delivers the message to the recipient.  Thus, the
de-referencing of any IMAP URLs needs to be done by the originating SMTP
server, in order to realize the benefit of shared network-based
authentication.

Therefore, a new type/subtype, perhaps a qualifier to one, or, even a new
SMTP command (ATTACH?) needs to be defined to trigger the dereferencing of
the URLs.

---

From: Doug Royer <[email-masked]>
Date: Mon, 09 Jun 2003 16:27:32 -0600

> SMTP command (ATTACH?) needs to be defined to trigger the dereferencing of

SMTP commands can not be embedded into the DATA stream. So I do not think
an ATTACH SMTP command will work. Although most MUAs display 'attachments'
in a separate pane, they are inline in just about any random order.

A simple example would be a reply to a long message where the person
replying wished to include the entire text of the original:

	users comments
		forwared-text expanded my MTA
	users signature

You could not insert an ATTACH or any other command into the SMTP/DATA
stream. It would have to be some kind of URL that the MTA recognized.

--

---

From: Randall Gellens <[email-masked]>
Date: Mon, 9 Jun 2003 23:24:09 -0400

>  in a separate pane, they are inline in just about any random order.

We would be creating a new Submit extension mechanism.  Such a 
mechanism could be as simple as saying 'expand references external 
body parts that have the "expand" flag set'.  Note that during the 
discussions on developing a separate SMTP submit service from the 
SMTP relay service, it was suggested that future Submit extensions 
that were only useful for message submission should perhaps look 
quite different from SMTP extensions, to prevent them from leaking 
into SMTP relay.  One example would be a kind of envelope wrapping 
the transaction.  At the time, there was discussion of using a Submit 
service for various sorts of helpful things, including transcoding of 
voice attachments, creating a proper message, etc.

-------------- Randomly-selected tag: ---------------
Nothing is illegal if one hundred businessmen decide to do it.
        --Andrew Young
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 10 Jun 2003 12:36:55 -0400

Hi Randall,

--On Monday, June 9, 2003 11:24 PM -0400 Randall Gellens 
<[email-masked]> wrote:

|>  SMTP commands can not be embedded into the DATA stream. So I do not
|>  think an ATTACH SMTP command will work. Although most MUAs display
|>  'attachments' in a separate pane, they are inline in just about any
|>  random order.
|
| We would be creating a new Submit extension mechanism.  Such a mechanism
| could be as simple as saying 'expand references external body parts that
| have the "expand" flag set'.  Note that during the discussions on
| developing a separate SMTP submit service from the SMTP relay service, it
| was suggested that future Submit extensions that were only useful for
| message submission should perhaps look quite different from SMTP
| extensions, to prevent them from leaking into SMTP relay.  One example
| would be a kind of envelope wrapping the transaction.  At the time, there
| was discussion of using a Submit service for various sorts of helpful
| things, including transcoding of voice attachments, creating a proper
| message, etc.

Can we have a clear statement of what exactly needs to be expanded for this 
application? The two possibilities I see right now are:

1) Expand entire MIME parts by substituting data from an outside source: 
external-body expansion.

2) Expand inline data (e.g. quotations in a reply or forward).

The former is relatively easy to do - just substituting one MIME part for 
another.

The later is much more complicated as it requires detailed knowledge of the 
data itself. This really requires a full-blown 'composition agent' that 
knows how to deal with character set and encoding issues for all components 
of the data being expanded, as well as data format issues (e.g. knows how 
to put together HTML fragments in a consistent manner). That definitely 
goes beyond anything that either SMTP or IMAP has had to do up till now.

If (2) is a requirement then I'd be more inclined to go with a third server 
option that has not been discussed much - namely having a new type of 
server a 'message composition server' that has all the logic and capability 
of a typical desktop MUA in terms of building rfc2822/MIME messages as well 
as the ability to pull in data from external sources (with an appropriate 
security model). As well as providing pointers to the source components of 
the message, the client of this server would also be able to specify the 
destination, which might be an IMAP server or an SMTP server or some other 
destination in a similar manner to IMAP CHANNEL. Has this third server 
option been ruled out for any reason?

---

From: Randall Gellens <[email-masked]>
Date: Tue, 10 Jun 2003 14:54:43 -0400

Hi Cyrus,

At 12:36 PM -0400 6/10/03, Cyrus Daboo wrote:

>  Can we have a clear statement of what exactly needs to be expanded 
> for this application? The two possibilities I see right now are:
>
>  1) Expand entire MIME parts by substituting data from an outside 
> source: external-body expansion.

This is what has been discussed to date, as far as I recall.

>  2) Expand inline data (e.g. quotations in a reply or forward).

I don't recall hearing of this before the most recent series of 
emails.  As far as I know this type of detailed composition server is 
not a requirement, because presumably the client would be capable of 
at least this level of composition.

>  The former is relatively easy to do - just substituting one MIME 
> part for another.
>
>  The later is much more complicated as it requires detailed 
> knowledge of the data itself. This really requires a full-blown 
> 'composition agent' that knows how to deal with character set and 
> encoding issues for all components of the data being expanded, as 
> well as data format issues (e.g. knows how to put together HTML 
> fragments in a consistent manner). That definitely goes beyond 
> anything that either SMTP or IMAP has had to do up till now.
>
>  If (2) is a requirement then I'd be more inclined to go with a 
> third server option that has not been discussed much - namely 
> having a new type of server a 'message composition server' that has 
> all the logic and capability of a typical desktop MUA in terms of 
> building rfc2822/MIME messages as well as the ability to pull in 
> data from external sources (with an appropriate security model). As 
> well as providing pointers to the source components of the message, 
> the client of this server would also be able to specify the 
> destination, which might be an IMAP server or an SMTP server or 
> some other destination in a similar manner to IMAP CHANNEL. Has 
> this third server option been ruled out for any reason?

If this type of composition service is required, then I'd tend to 
agree with you that it goes far beyond current IMAP or Submission 
capabilities and would need a new server, part of a full-blown split 
client mode.

-------------- Randomly-selected tag: ---------------
There once was a hacker named Ken
Who inherited truckloads of Yen
        So he built him some chicks
        Of silicon chips
And hasn't been heard from since then.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade