Gonzalo Camarillo wrote:
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).
Right. That case makes no sense to construct.
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.
Yes. IMO it is important to get a consistent framework in place that
covers whatever kinds of usage might come along. Without that people may
invent processing algorithms that cover only the cases they happen to
have encountered.
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.
Hmm. I guess that makes sense. It means that any time there is an
optional header with a reference to a body part then the handling of
that body part needs to be optional. But again I guess that makes good
sense.
Some interesting questions arise when body parts are being processed by
middleboxes. (Maybe we aren't supposed to talk about that here.) The
whole issue of handling=required gets messy there. The middlebox isn't
the intended recipient, so the handling parameter doesn't really apply
to it. So presumably it processes whatever headers and body parts it
likes. That is another motivation for making the decision about
processing be explicit - so it can be selective.
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.
Me too. So far this has mostly been a dialog between the two of us.
(Dale? - I can usually count on you to have an opinion.)
Paul
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
