ietf-smtp
[Top] [All Lists]

RE: I-D ACTION:draft-shveidel-mediasize-00.txt

2002-06-09 00:32:43
Hello Dan,

First - an administrative suggestion. I suggest that discussion of this I-D
is done in the UM mailing list (um(_at_)snowshore(_dot_)com) 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:dwing(_at_)cisco(_dot_)com]
Sent: Friday, June 07, 2002 12:59 AM
To: Shveidel, Vladimir; Erev, Ari
Cc: ietf-smtp(_at_)imc(_dot_)org; vpim(_at_)lists(_dot_)neystadt(_dot_)org; 
um(_at_)snowshore(_dot_)com
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

<Prev in Thread] Current Thread [Next in Thread>