Subject: RE: I-D ACTION:draft-shveidel-mediasize-00.txt
From: "Erev, Ari" <[email-masked]>
To: "'Dan Wing'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], "Shveidel, Vladimir" <[email-masked]>
Date: Sun, 9 Jun 2002 10:33:39 +0300
List-Id: <ietf-smtp.imc.org>

Hello Dan,

First - an administrative suggestion. I suggest that discussion of this I-D
is done in the UM mailing list ([email-masked]) so as not to duplicate the
discussion on all the above lists.

I am still sending my reply to all the three lists but suggest to limit
future communications only the UM list.

My answers inside.

Regards,
Ari

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 12:59 AM
> To: Shveidel, Vladimir; Erev, Ari
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: I-D ACTION:draft-shveidel-mediasize-00.txt
> 
> 
> > 	Title		: SMTP Service Extension for message Media Size 
> >                           declaration
> > 	Author(s)	: V. Shveidel, A. Erev
> > 	Filename	: draft-shveidel-mediasize-00.txt
> > 	Pages		: 12
> > 	Date		: 04-Jun-02
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-00.txt
> 
> Hi.
> 
> I'm unable to understand the underlying architecture that caused
> you to create this I-D.  What architecture of a message store 
> prevents it from storing, say, 1Mb of audio but allows it to 
> store 1Mb of plain text?

As stated in the 'abstract' section - this I-D is one of the issues and
requirements raised by draft-vaudreuil-um-issues-00.txt (see: 3.2 in it).

Here is a relevant part from draft-vaudreuil-um-issues-00.txt:

It is common in a unified messaging system to offer separate quota's for 
each of several message contexts to avoid the condition where a flood of 
email fills the mailbox and prevents the subscriber from receiving voice 
messages via the telephone.  It is necessary to extend the protocols to 
support the reporting of the "mailbox full" status based on the context 
of the submitted message.   

While the preliminary text in draft-vaudreuil-um-issues-00.txt only talked
about 'Quota by context' this draft expands a bit so as to (optionally)
allow 'quota by media' - where a message of a certain context may hold more
than one media type.

We hoped that a discussion on the list will consider the enhancement and
decide whether it is required - or the less flexible 'quota by context' is
enough.

> 
> How is an SMTP client supposed to map the MIME types of a 
> message to the media types (voice-message, fax-message,
> video-message, text-message) that you enumerate in section
> 9.1 of your I-D?  What of MIME types that the SMTP client
> doesn't recognize - how are they to be handled?
>

This I-D builds on some "work-in-progress' done in VPIM, and specifically on
the "Message-Context" I-D (draft-ietf-vpim-hint-08.txt) which is assumed to
be used by a "Unified- Messaging-enabled" SMTP client. A non-conforming SMTP
client will still work but will not get the benefit of knowning _in advance_
whether the server is ready to accept this message due to its media/context
size. This is similar to an SMPT client that does not use the SMTP Size
Extension.

> I found no registration facility for the units used in 
> examples in your I-D (kb, sec, pages).  Unfortunately, the
> mechanism to convert or validate one unit to another is
> vague.  Further, the premise of the entire document is that
> an architecture of an SMTP message store doesn't permit
> it to store "large" media parts -- yet, the size of a 
> media part isn't indicated by its duration (seconds) or
> length (pages).  Rather, only a count of bytes is 
> meaningful.
> 
As for the registration facitiliy - I think we suggested to consider two
options: either to extend the "Message-context" registration with these
units, or to extend the 'content-type' registration with these units. 

As to the mechanism to convert/validate one unit to another - I agree it is
somewhat vague. This is because we assumed it to be an implementation issue
and not a protocol definition. For example, in the case of voice-mail
systems, they usually support a limited number of formats/codecs and then
the conversion is more straight forward. I agree that the general case of
supporting all sorts of media and encodings is much more complicated and
(IMHO) is out of the scope of this I-D.

> If you could help me understand the background for this
> I-D, I'll be happy to discuss some other questions I have
> with this document.
As written above - the context is: draft-vaudreuil-um-issues-00.txt.

> 
> -d
>