On 7/4/08 1:28 PM, Paul Kyzivat wrote:
Adam,
I have to admit that I still haven't grokked the distinction between
multipart/mixed and multipart/related.
From a data structures perspective, multipart/mixed is an unordered
set, while multipart/related is a tree. The difference is actually
pretty radical.
I gather this discussion is specific to related, not mixed. So would
the issues you raise not be of concern if we used mixed rather than
related to carry the multiple parts?
You're throwing the baby out with the bathwater. This issue would go
away, but the solution would be tortured. We would have to add semantics
on top of multipart/mixed that, when we were done, would make it
effectively identical to multipart/related.
If I may draw an analogy -- SDP was originally developed for use in
things like SAP (RFC 2974) and SIP for multicast sessions. As such, it
made perfect sense to normatively require the inclusion of contact
information in SDP (RFC 2327, section 6: "Either an email field or a
phone field must be specified").
However, when we started doing point-to-point SIP sessions, this
constraint stopped making much sense. The person responsible for the
session is the person you're talking to -- mandating the inclusion of
additional contact information didn't make sense anymore.
Now, we could have elected to skirt this problem by observing, for
example, that FTP (RFC 959) already contains a means for establishing
connections -- all we need to do is add syntax for conveying media
types, codecs, etc. It certainly would be an *effective* way of skirting
the restriction in RFC 2327 that we don't like.
Or, we could have observed that RFC 2327 gets us well over 99% of the
way to where we want to go -- save for this one restriction that makes
no sense in the context we're trying to use it in -- and just use it.
Happily, this is what we did.
/a
_______________________________________________
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
