Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt

[Paul Kyzivat]

Gonzalo Camarillo wrote:
Hi,

FYI: we have just gotten their review:
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00110.html

Cheers,

Gonzalo

Looks like there is a *bit* more work to do. :-)

This is perhaps somewhat more feedback than we were hoping for. But 
honestly it does seem constructive.

However on several of what I thought were key points needing feedback I 
don't see the help I was hoping for. For instance regarding references. 
Perhaps more interaction is needed to get on the same wavelength so that 
Dave understands our concerns and we understand his answers.

        Paul


Gonzalo Camarillo wrote:
Folks,

FYI: we have requested the apps folks to have a look at this draft in 
order to make sure we get all the MIME stuff right. We will make sure 
the review is posted to this list.

Cheers,

Gonzalo


Gonzalo Camarillo wrote:
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




_______________________________________________
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