IMO this MUST be an update to 3204. It is tightening down incomplete
specification. Without it being mandatory it isn't helpful.
IMO this SHOULD be an update to 3261. There are just too many needed
uses of multipart that just won't work if you can't count on it being
supported. The alternative is to try it, and if it fails, try again
without the multipart. That presumes it makes sense to leave something
out to get down to one part, and you can guess *which* part to fall back
to. OTOH, making it mandatory won't make it happen. But I think that may
just be a matter of giving some time, as long as it has been made mandatory.
Thanks,
Paul
DRAGE, Keith (Keith) wrote:
In reviewing the document I have the following comments. In general I
found the document appropriately complete and ready for submission.
1) Does the document update RFC 3261. The particular normative
statement I am thinking of is:
For all MIME-based extensions to work, the recipient needs to be able
to decode the multipart bodies. Therefore, SIP UAs MUST be able to
parse 'multipart' MIME bodies, including nested body parts. In
particular, UAs MUST support the 'multipart/mixed' and 'multipart/
alternative' MIME types.
My understanding is that we do not want to regard this as an extenision,
i.e. we wish all RFC 3261 implementations to abide by it. Does that
therefore not mean an "updates".
2) Does the document update RFC 3204. Here the particular
requirements I am thinking of is:
If at least one of the body parts within a 'multipart/mixed' body has
a 'handling' value of 'required', the UA MUST set the 'handling'
parameter of the 'multipart/mixed' body to 'required'. If all the
body parts within a 'multipart/mixed' body have a 'handling' value of
'optional', the UA MUST set the 'handling' parameter of the
'multipart/mixed' body to 'optional'.
If the handling of a 'multipart/alternative' body is required, the UA
MUST set the 'handling' parameter of the 'multipart/alternative' body
to 'required'. The UA SHOULD also set the 'handling' parameter of
all the body part within the 'multipart/alternative' to 'optional'
(the receiver will process the body parts based on the handling
parameter of the 'multipart/alternative' body; the receiver will
ignore the handling parameters of the body parts). The UA MUST use
the same disposition type for the 'multipart/alternative' body and
all its body parts.
Again this seems to be further specifying the handling parameter defined
in RFC 3204 rather than defining an extension.
3) Section 4.3:
UAs SHOULD avoid unnecessarily nesting body parts because doing so
would, unnecessarily, make processing the body more laborious for the
receiver.
I had some problem with this because it seems an impossible statement to
determine conformance to. Is the RFC 2119 language therefore
appropriate.
4) Section 11, IANA considerations.
Should the following registry not be updated to add a reference to this
draft (in addition to [RFC3261]):
Registry Name: Header Field Parameters and Parameter Values
Reference: [RFC3968]
Registration Procedures: Published RFC (A standards-track RFC is NOT
required)
Registry:
Predefined
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
---------
Content-Disposition handling Yes
[RFC3261]
I also had a number of editorial comments which I have sent directly to
Gonzalo.
Regards
Keith
_______________________________________________
Sip mailing list https://www.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://www.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
