Re: The issue of mime parsing

At 1:43 PM +0100 27/3/03, Rickard Armiento wrote:

>Andrew Rutherford:
>>  And it doesn't require changing the MIME standard in any way,
>
>I only partially agree here: it requires specifying that only a
>subset of MIME is allowed for im2000 'manifests'. If generic MIME is
>allowed, we would still need to parse it in the im2000 server, which
>was what we started out trying to avoid.

Yup, I consider a subset fine. What I was objecting to was something 
different, as it helps if programmers can use their existing 
MIME-handling tools and libraries *if they wish to*.

On a different issue, RFC 3264, "An Offer/Answer Model with the 
Session Description Protocol (SDP)" describes something in my 
previous SIP example that's relevant here.

In negotiating codecs over SIP, the idea is that in the first packet 
from the initiator, it proposes a preference list of acceptable 
codecs - basically everything it supports. In the 200 response, the 
receiver sends back just the one that they picked, which is then 
acknowledged by the initiator in an ACK.

This has obvious implications when talking about "negotiating" 
acceptable encryption keys, given the SIP messages are end-to-end. 
The sender of the email could propose a list of encryption keys and 
techniques supported in preference order, and the receiver can 
respond with the one they have picked, or a message saying none were 
acceptable (which may give an alternate proposal list, which could 
lead to another round). The sender can then encode the email parts 
and place it into the appropriate storage facility before sending the 
ACK, and which point the receiver knows the parts can be picked up.

Now, the next bit depends on if the SIP message body is encrypted or 
not. If not, proxy servers in the path could modify the preference 
order to meet the specified policy requirements (eg, X is preferred 
over Y). This is typically used in the VoIP world by proxy servers 
who understand the network topology so know for a particular call if 
a low or high bandwidth codec is appropriate.

-- 
Andrew Rutherford      sip:[email protected]      244 Pirie Street
Iagu Networks          tel:+61-8-8425-2255       Adelaide SA 5000
http://www.iagu.net/   mailto:[email protected]   Australia