Glenn Parsons (gparsons@nortelnetworks.com)
Thu, 20 Jul 2000 18:36:42 -0400
> You wrote:
>
> NOTE: We could choose the default value for Content-Notification to
> be IGNORE. This would make VPIMv2 automatically compliant with this
> document, as VPIMv2 has provision to silently delete undeliverable
> parts. However, VPIMv2 systems should not be receiving arbitrary e-
> mail from the Internet. If they do, they should be compliant with
> this series of documents. By defaulting to NOTIFY, this draft is
> compliant with the rest of the Internet infrastructure.
>
>
> I disagree with the assertion that VPIM-2 systems should not be "receiving
> arbitrary e-mail from the Internet". For example, Microsoft Exchange 2000
> can act as a VPIM-2 server, receiving email messages of all types from the
> Internet and sorting out which are VPIM-2 messages. The identification of
> VPIM-2 messages is not difficult - it is after all a well-defined MIME
> profile. More to the point, I don't remember anything in the VPIM-2 RFCs
> that precludes this behaviour, or even suggests that it is undesirable.
>
The point is that if a system was designed to be 'VPIM v2 only', the
original expectation is that it would not be "receiving arbitrary e-mail
from the Internet" However, since email servers like Exchange 2000 are
adding VPIM v2 support the assertion that VPIMv2 systems cannot accept
arbitrary email becomes confusing.
In VPIM v2 (RFC 2421) we included text that delineates what you should do in
cases where you would get such a message. When we wrote it, our expectation
was that there would be a lot of VPIM v2 only systems -- and that was our
target audience. So, from the what was implemented files, the typical
reaction of a VPIM v2 only system has been to reject these arbitrary
messages. While systems that support 'multimedia messaging', 'unified
messaging' or just 'email' will typically accept all messages and just
delete pieces (if they have to) to deliver the VPIM v2 message.
As a result, we have modified the text in VPIM v2 r2 to reflect this.
The tricky part, as we are now seeing in IVM is that the desired behaviour
is for the server to accept everything and then work out with the client
(which can be anything from a POTS phone, to a WAP phone, to a desktop PC)
what it can accept and how to display it. The next question is then what
NDNs (if any) are sent. These are the issues with which I see primary and
critical content helping us.
Cheers,
Glenn.
This archive was generated by hypermail 2.0b3 on Fri Jul 21 2000 - 01:37:44 IDT