Hi,
to be more concrete in our discussions, we need to make decisions on the
following two issues:
1) Where in a SIP message is it allowed to reference a body part?
a) in header fields and body parts within the same multipart/related as
the referenced body part
b) in header fields and body parts that appear before the referenced
body part
c) in header fields and any body part
We discussed that doing c) would require to parse SIP messages twice to
look for potential references. Therefore, we decided to do a) or b). The
current draft specifies a), we doing b) might make sense as well (it
would be less restrictive).
2) If a receiver does not understand a reference to a body part:
a) it should process (handle) it solely based on its disposition type
(as a fall-back mechanism). If the sender does not want this to happen,
it can use an option tag.
b) the body part will have a disposition type of "only-by-reference".
This way, since the receiver did not understand the reference, it knows
it should not process the body.
The current draft specifies a), but b) would be an interesting
optimization (no need to use option tags and reissue requests). However,
we would need to get the opinion of a MIME person on b).
Cheers,
Gonzalo
Paul Kyzivat wrote:
Eric Burger wrote:
I agree 100% with Paul. However, one thing I would like to hear
opinions on
is the following:
Do we way body parts are always processed, no matter what?
It would be convenient to say body parts get processed as needed. If
there
is a related part that never gets referenced, then a conforming processor
might not process that part, as an optimization.
This gets into semantics...
For one thing, I guess we should talk about "handling" rather than
"processing" - this is tied to the C-D "handling=" parameter.
But the key thing is what does it *mean* to say you have handled
something? Its one thing to understand the meaning of the type and
disposition. What you actually *do* once that is understood is something
else entirely.
I would expect that somewhere there would be a normative specification
for each C-D of what it means to *handle* body parts with that
disposition. This is where we get into trouble with "render", where we
need a different definition for SIP than is used for email.
I presume that if we had such normative definitions, then that would
determine what sort of optimizations, such as lazy processing, are allowed.
For example, 3261 defines (barely) the C-D "alert". It says this
"should" (lower case) be rendered. Together with some words elsewhere
about Alert-Info that warn of security issues, its seems clear that the
UA is given discretion about actually rendering this. (But it is not a
stellar example of clarity.) I would interpret this to mean that you can
consider the "alert" body part to have been "handled" if you have indeed
understood it and then *either* rendered it or made an explicit not to
render it.
However, one thing we need to be mindful of are side effects. MIME body
parts can make external references. Those external references (to
http/https URI's) may hit application servers. Those application servers
may do something based on the receipt of the URI. It could be as
simple as
recording the fact the body part was read (like a web beacon), or it
could
be as complex as changing application state.
We have similar issues with headers that contain URL references, that
might or might not be resolved. E.g. Call-Info.
Again, I don't see any general answer better than the specification of
the particular header or C-D.
Based on this discussion I am beginning to conclude that we might as
well treat each body part almost as if it were a header whose name is
its C-D.
What do people think of this? Do we say that SIP engines are
opportunistic,
and the side effect MUST happen if the body gets used, buy the side
effect
MAY happen if the body does not get used? That would be my vote, as the
alternative, that all side effects (external references get resolved)
happen
puts a pretty big burden on User Agents.
This is further complicated by intermediate nodes. They are *permitted*
to look at body parts. If, as a result, an intermediate node
dereferences a reference within a body part, you will potentially have
another side effect.
I also agree that we should give the UA latitude in what processing it
does. For example, even though a request has a geopriv header with a
body part containing location data, and has specified
"handling=required", the UAS may have no use for the location. If it
doesn't intend to use it then why should it process it?
Paul
On 8/29/07 8:57 AM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:
To clarify futher my last point below...
What I am saying is that IMO body parts must always be processed
according to their type and disposition, whether there are references to
them or not. If there is a reference, and it is understood, then it can
modify or supplement the processing, but if the reference is not
recognized or understood then the other processing still occurs.
If we want to support the possibility of a reference to a body part,
where there is to be no processing of the body part when the reference
is not understood, then we need a content-disposition that says "don't
do anything with this unless you process a reference to it."
An alternative is to simply assume there are no such cases, and warn
people that use references to select a C-D for the referenced part that
will have an appropriate result if the reference is not understood.
For instance, we have both the Alert-Info header and the "alert" C-D. If
you use an A-I with a CID reference, then you can use "alert" as the C-D
of that part. In that case, the A-I header is redundant unless it
contains something that modifies the processing.
An example where the problem I am concerned about may exist is in
draft-ietf-sip-location-conveyance-08. It has an example of a
Geolocation header referencing a body part. There is no C-D header in
the example, so by default it is "render;handling=required". And its C-T
is application/pidf+xml. If a recipient of this message didn't
understand the Geolocation header it would reach the conclusion that it
should render the pidf. Its debatable whether that is the desired
conclusion - I think not. IMO the intent is that if the Geolocation
header isn't processed then the pidf should be ignored. So, IMO this
body part ought to contain:
Content-Disposition: by-reference;handling=optional
(I don't care what name we use for the disposition, just that we have
one.)
Thanks,
Paul
Paul Kyzivat wrote:
Gonzalo,
Obviously we allow a "forward" reference from the sip message itself
(which from a mime perspective are just a bunch of mime headers.)
I think that establishes a precedent that needs to be continued. An
example of why can be seen in sipfrag:
If we had a valid sip response that had a reference into one of its
body
parts, then if that was turned into a sipfrag and stuffed into the body
of a NOTIFY, then it must still be valid.
I just did a quick scan of the new draft, so the following is a
tentative comment, until I can read it more carefully:
I think the draft is now saying that the decision about whether to
process a body part according to a reference to it, or process
independently, is decided based on whether a reference is found. We had
this discussion before, and I think we agreed that wouldn't work well,
and that instead we would have a special C-D type for body parts that
are disposed of based on a reference.
I don't think the introduction of issues related to multipart/related
changes this. The obvious cases are when there is a single
multipart/mixed containing some body parts. Some of those may be
referenced from CID URIs in sip headers, and others (e.g. SDP) may
stand
on their own. It is entirely possible that a body part might be
referenced from some extension header that the recipient doesn't
understand. In that case it may erroneously decide to process the body
part on its own, when it should instead have ignored it because the
header isn't being processed.
Thanks,
Paul
Gonzalo Camarillo wrote:
Folks,
I have just submitted a new revision of the body handling draft. Until
it appears on the archives, you can fetch it from:
http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt
Per our discussions in Chicago, the draft now states that only body
parts within the same 'multipart/related' can reference each other
using cid URIs.
If this is too restrictive, we could also allow using forward
references in any context (with no 'multipart/related' at all).
Comments?
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
_______________________________________________
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
_______________________________________________
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
Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for the
use of the individual or entity named in this message. If you are not
the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.
_______________________________________________
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
