Responding further on: > > 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.
The key thing we need to do is write a statement where we clearly understand whether the implementor has chosen not to apply the constraint. Is it possible to write "SHOULD NOT nest" in this case, and then give some examples of where we might expect that to be broken. That then gives a clear test of conformance to the requirement, and the assessor of conformance can then decide whether breaking the SHOULD was acceptable or not. If there are key aspects where be know nesting are best used, then maybe we should bring those out as separate requirements in RFC 2119 language, i.e. if <condition> then MUST nest else SHOULD NOT nest. But I suspect that we do not actually have anything specific for this. Speak up if anyone knows of any. I know we do have this paragraph in section 4.1: Nested MIME bodies are yet another useful tool to build and combine SIP extensions. Using the extensions in the previous examples, a UA that supported a new session description format and that needed to include a location object in an INVITE request would include a 'multipart/mixed' body with two body parts: a location object and a 'multipart/alternative'. The 'multipart/alternative' body part would, in turn, have two body parts: a session description written in SDP and a session description written in the newer session description format. But thinking about this, I suspect we define no semantics anywhere (please correct me if I am wrong) about what nesting means. Does a nested body require different interpretation to a multipart body, and if so, how do I discover what that difference is. All the nesting would seem to tell me is that there might be a different relationship, but it does not tell me what that relationship is. Regards Keith Regards Keith > -----Original Message----- > From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] > Sent: Friday, July 25, 2008 8:45 AM > To: DRAGE, Keith (Keith) > Cc: SIP IETF > Subject: Re: Comments on draft-ietf-sip-body-handling-02 > > 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
