Re: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt

[Paul Kyzivat <[e-mail]>]

Randall,

(Including ecrit)

On 9/22/16 12:26 PM, Randall Gellens wrote:
> Hi Paul,
>
> Thanks very much for the quick review and comments.  I'm making other
> changes requested by Christer, and I want to fix the ones you found as
> well.
>
> Section 12 is the Security Considerations.

In the -10 version I am looking at section 12 is Examples.

> Did you mean Section 11, the
> Examples?  Or maybe Figure 10 (one of the examples)?   More to the point
> on correct C-D, there's text in Section 6 that says:
>
>    If the body part
>    containing the MSD or metadata/control block is the only body part,
>    it has a Content-Disposition header field value of "Info-Package;
>    handling=optional".  If it is contained within a multipart body part,
>    it has a Content-Disposition header field value of "By-Reference;
>    handling=optional".
>
> So this is wrong?  What should it say?

That text seems ok, at least for this case.

IIUC it isn't discussing the C-D *on* the multipart/mixed container. It 
is discussing parts *within* the multipart. Those seem to be correctly 
tagged.

The "Info-Package" C-D is only applicable for an INFO message. Since 
this isn't an INFO message it makes no sense to use it.

The authoritative document on this stuff is RFC5621.  However it is 
silent on what C-D used be used for multipart containers. So it is 
necessary to read between the lines to figure that out.

1) Consider an ordinary INFO message. It will have a body with C-D of 
"Info-Package", indicating that it is to be processed as the package for 
this INFO.

2) Next, add a header that needs to reference a body part, such as 
geolocation. Now we have two body parts, and need a multipart wrapper to 
contain them. One body part has C-D of "Info-Package" for the INFO, and 
the other has C-D of "by-reference" because it is referenced by the 
geolocation header. The multipart that wraps them needs *some* C-D. IMO 
it shouldn't be Info-Package because that would imply that the whole 
thing is to be used by the INFO message. It shouldn't be "by-reference" 
because it isn't referenced by anything. It is really processed in a 
special way, and we have no special C-D value to signify this. If 
omitted it will default to C-D:render,handling=required. Having it be 
required is appropriate in this case, since the handling of the info 
package is also required. The "render" value seems as good as any, since 
the contained parts have their own dispositions and "rendering" a 
multipart independent of its contents also seems to have no meaning.

3) A similar situation to (2) holds for INVITE. In this case of an SDP, 
the default C-D is "session".

4) For some message that doesn't require a body part for its own 
processing (e.g., UPDATE) and a single header with a CID reference. Then 
there will be no multipart - just the referenced part. It will still 
have a C-D of by-reference.

5) A message with no body part of its own, but multiple CID references 
from headers to body parts, will need a multipart body containing the 
referenced body parts. It will be much like (2) but without the 
Info-Package part.

> Section 10 (the INFO package registration) says:
>
>    If the body part is the only body
>    part, it has a Content-Disposition header field value of "INFO-
>    Package; handling=optional".  If the body part is contained within a
>    multipart body part, it has a Content-Disposition header field value
>    of "By-Reference; handling=optional" (the top-level multipart body
>    part has "INFO-Package" in its Content-Disposition value).
>
> So this is also wrong, especially the parenthetical statement that the
> top-level has a C-D of INFO-Package?  What should it say?

Hopefully the above is sufficient.

> Also, when you say "let it default to render" you mean just omit the C-D
> header field?

Yes. But that must be done with care, since it implies 
handling=required. If processing of the headers with references isn't 
required then that ought to be changed to handling=optional.

	Thanks,
	Paul