New revision of draft-ietf-sip-body-handling-00.txt

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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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://ww
w1.ietf.org/mailman/listinfo/sip
>  >> This list is for NEW development of the core
SIP Protocol
>  >> Use sip-implementorscs.columbia.edu for
questions on current sip
>  >> Use sippingietf.org for new
developments on the application of sip
>  >>
>  >
>  >
>  > _______________________________________________
>  > Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>  > This list is for NEW development of the core SIP
Protocol
>  > Use sip-implementorscs.columbia.edu for
questions on current sip
>  > Use sippingietf.org for new developments on the
application of sip
>  >
> 



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Eric - we need your input here as our mime guru.

	Paul

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

It seems that multipart/related has some role to play. I am
not entirely 
clear what that is. I think it clearly isn't enough by
itself.

> 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?

Well, we clearly have a need for references from the sip
message itself 
to body parts that it contains. I guess that is a restricted
form of 
forward reference. Perhaps it, plus the usage within
multipart/related, 
is sufficient.

This reference into a contained body part does need to apply
even when 
the reference itself is in a body part. An example of this
is to take a 
sip message that uses this form and put the whole thing into
a sipfrag.

> 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...

I do think we need input from a mime guru. Eric: please
guide us on how 
to do this in a mime-compatible way.

	Paul

> 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://ww
w1.ietf.org/mailman/listinfo/sip
>>  >> This list is for NEW development of the
core SIP Protocol
>>  >> Use sip-implementorscs.columbia.edu for questions on current sip
>>  >> Use sippingietf.org for new
developments on the application of sip
>>  >>
>>  >
>>  >
>>  >
_______________________________________________
>>  > Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>>  > This list is for NEW development of the core
SIP Protocol
>>  > Use sip-implementorscs.columbia.edu for
questions on current sip
>>  > Use sippingietf.org for new
developments on the application of sip
>>  >
>>
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

   From: Gonzalo Camarillo <Gonzalo.Camarilloericsson.com>

   http://users.piuha.net/gonzalo/temp/draft
-ietf-sip-body-handling-00.txt

Reading this draft I was struck by:

   UAs MUST use the binary transfer encoding for binary
payloads in SIP.

Firstly, this specification is orthogonal to everything else
in the
I-D.  Nonetheless, it is an important point.

Secondly, what about non-binary payloads, etc.?  Don't you
really
mean:

   UAs MUST use only the "binary" content transfer
encoding in SIP.

Dale


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip