Hi Paul,
thanks for your comments. Yes, this is the open issue we need to close
in order to move forward. We have really two issues:
1) In Chicago, people talked about multipart/related and the possibility
of restricting references between body parts to bodies within a
multipart/related. The current revision of the draft specifies that so
that we can discuss whether or not it is what we want to do.
Another way of restricting which bodies can reference other bodies would
be to only allow forward references. That is, a body can only reference
another body if the latter body appears after the former. Do we have
examples where a body would like to reference another one that is not
part of the same multipart/related?
2) Then, we have the issue of what happens when the receiver does not
understand the reference. Right now the draft says that extensions
should take care of this case. However, we could say something more
about that. For example, multipart/related addresses this issue saying
that if the receiver understands multipart/related, it ignores the
disposition types of the body parts within it. However, if the received
does not understand multipart/related, it will treat it as
multipart/mixed and, thus, will process the body parts based on their
disposition types.
Defining a disposition type that means "don't process me unless you find
a reference to me" would be a good way to have receivers ignore body
parts. It works better than an option tag because the sender does not
need to resend its request. It would be good to get more opinions on this...
Cheers,
Gonzalo
Paul Kyzivat 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
