Hi Paul,
Thanks for sending out in advance. Maybe we can get into the discussion
of the slides now, before the meeting.
yes, that was the intention.
Regarding references to body parts:
IMO it is a *bad* idea to make the decision about processing of a body
part "on its own" dependent on whether the node doing so has detected a
reference to that body part or not.
For one thing, that requires a multi-pass parsing mechanism to check for
references before deciding what processing to do on a particular part.
For another, it requires that the recipient understand every reference.
For instance, the sender may have included an extension header that
contains a reference to a body part. If the extension isn't understood,
then the body part should not be processed. But if the recipient doesn't
understand the extension then it won't recognize the reference either,
and so will attempt to process the body part as one without references.
yes, these two issues are described in the draft.
The only good solution I see to this is to partition the
Content-Disposition and/or Content-Type values whose processing is
dependent on reference from those whose processing is not dependent on a
reference. For instance, we could simply define a new
Content-Disposition of "by-reference".
Then a normal sequence of processing would be to first process all the
body parts according to their type and disposition alone. Any with
disposition "by-reference" would be set aside. Then, when processing
headers, if a header with a reference is encountered the appropriate
processing could be applied to the set aside body part. References
within other body parts would be a little more complex, but you get the
idea.
yes. When looking for references, one would need to process the header
fields plus the body parts with a disposition type different than
'by-reference', since, as you point out, those body parts could contain
references to 'by-reference' body parts.
The only case we would not cover would be two (or more) 'by-reference'
body parts referencing each other. But we can just say that this is
forbidden (no extension does that at present).
This would not prevent reference to body parts with other dispositions.
It just means that those body parts would also be processed according to
their type and disposition, in addition to any processing they might get
according to their reference. The "by-reference" disposition is just a
defintion that gets no implicit processing.
yes, the draft already talks about the possibility of having several
references to a body part. In such a case, the body part would need to
be processed several times (in different ways). However, the case you
are talking about is not currently addresses (i.e., a body part is
processed once based on a reference and another time based on its
content disposition). None of these situations occur within current
extensions, but they could happen in the future.
An advantage of this approach is that by-reference body parts don't need
to be parsed unless the reference is processed and the action required
in processing the reference requires the node to parse the referenced
body. (Interaction with handling=required in this case is TBD.) Even a
multipart with disposition of by-reference might not need to be parsed.
The interaction with handling=required would be that if you are not able
to find a reference to a 'by-reference' body part with
handling=required, you report an error because you have not been able to
process the body part.
This approach would work and has the advantage to be explicit about how
a body part is expected to be processed... I would like to hear more
opinions on this.
Cheers,
Gonzalo
Gonzalo Camarillo wrote:
Folks,
here you have the slides I have put together for the body (MIME)
handling presentation on Monday:
http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt
These slides relate to this draft:
http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt
The slides discuss all the open issues that have been brought up in
the list in the last months.
Comments are welcome.
Thanks,
Gonzalo
_______________________________________________
Sip mailing list https://www1.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
