From: Paul Kyzivat <[EMAIL PROTECTED]> I'd still like to know if email clients need to do this two pass approach - first searching for all the references to determine if all the handling requirements can be met, and then actually doing the processing of the referenced parts?
Well, if you want to be able to process all valid MIME multipart bodies, it seems to be unavoidable. As far as I can tell, almost all of the algorithm is prescribed by the RFCs. The only specification I've added is the subtle question of what strategy will be used to choose from multipart/alternatives. My first discussion some months ago, I used the strategy "Can you choose so that the constraints are satisfied?", which led to NP-completeness. This version, which is probably closer to what is intended by the RFCs, is "Make the choice for each multipart/alternative without regard to whether it is adverse to multiparts that contain you." Also, it *is* legal for proxies to process bodies. But its obviously not required (by the protocol) for them to do so. Do we have a clue how the handling parameter applies to proxies? I assume in effect they can just ignore it and consider handling to be optional for all parts. Also, I presume a proxy that cares about body parts might want to investigate all the alternatives of a multipart/alternative, since it can't know which one the recipient will choose. As far as I can tell, proxies aren't allowed to reject messages because they don't like their bodies, although I'm sure that in specialized applications, they will. But the interpretation of handling parameters by such proxies will be determined by what the "specialized application" is attempting to do; it's not in the scope of RFCs. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
