Hi Keith,
thanks for your comments. Answers inline:
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".
yes, I think this document should update RFC 3261. I will add that to
the draft.
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.
Yes, I will also add to the draft that it updates RFC 3204.
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.
Well, you are right that the "unnecessarily" makes it sound like a
motherhood-and-apple-pie statement. But you could actually check
conformance to it. If an implementation nests a body part without having
a specific reason to do it, then it is not conformant. Any implementer
should know why he or she is doing something. So, I would like to keep
the capitalized SHOULD. In any case, if you have a strong opinion on
this, it would not be a big deal for me to make the statement
non-normative instead.
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]
yes, that is probably be a good idea. I will add that to the draft.
I also had a number of editorial comments which I have sent directly to
Gonzalo.
Yes, I will introduce those editorial changes in the next revision of
the draft.
Thanks,
Gonzalo
_______________________________________________
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
