Hi Eric,
thanks for your comments. We had already agreed to request the
publication of 05. We were just waiting for the chairs to do or get
someone to do the PROTO write up for the draft (the PROTO write up has
already been done at this point).
In any case, I will revise the draft so that the revision we use for the
publication request (06) will include your comments. My answers inline:
Good work and almost done!
General
=======
Many of the rules for multipart/mumble say things like "all parts must
be foo." This construction is not strictly correct. For example, in
multipart/alternative, I could have a multipart/mixed. Saying something
like "all parts in a multipart/alternative must be marked foo" means
that ALL parts, including walking down the multipart/mixed contained
therein, must be marked foo. What we really want to say is "all
top-level parts in a multipart/alternative must be marked foo." That
means, for example, if one of the parts is a multipart/mixed, the
multipart/mixed needs to have the foo marking, but things within the
multipart/mixed, I presume, will follow the appropriate rules for
multipart/mixed and the body's context.
Good point. I have fixed it.
Section 3.2
===========
Please make clear that binary *SIP* message body parts MUST be binary,
as the text currently says. However, it is quite possible, and should be
legal, to encode application parts transported in SIP, such as INFO or
NOTIFY bodies. For example, one might forward a base64 e-mail or a
uuencoded file. Since that would be an application-level message, there
is no reason to burden the application with decoding the body part to
get it to binary, just for the other side to re-encode it.
I have added the following:
"The only
case where a UA MAY use a different encoding is when transferring
application data between applications that only handle a different
encoding (e.g., base64)."
Section 6.2
===========
What confused me is section 6.2 starts with what looks like a normative
statement, but it really is a forward reference. To me, there is no
reference to which 'same' we are referring to. The text then seems to
jump to what looks like a special case for 'session' and
'early-session'. I would suggest the following:
6.2. UA Behavior to Generate 'multipart/alternative' Message Bodies
Section 8.2 mandates all top-level body parts within a
'multipart/alternative' have the same disposition type as the enclosing
'multipart/alternative'.
The 'session' and 'early-session' [RFC3959] disposition types require
that all body parts of a 'multipart/alternative' body have different
content types. Consequently, for the 'session' and 'early-session'
disposition types, each top-level body type within the
'multipart/alternative' body MUST be different. Otherwise, the rules
for the specific disposition type apply.
NOTE: One could envision situations where a UA presents multiple
alternatives with the same body type, where the receiving UA picks the
best or richest alternative it can use.
I have split the paragraphs as you suggest. I agree it makes the text
clearer. However, I have stick to using the active voice for normative
text, which is the trend nowadays (e.g., the UA MUST set the parameters
to different values instead of the values of the parameters MUST be
different).
Section 6.3
===========
Ah, but there ARE handling rules for multipart/alternative. I would
replace this section with:
When a UA receives a message with a 'multipart/alternative' body
part, if the body part has a 'required' handling, then the UA MUST pick
the best alternative body part to use. If the UA is unable to use any
of the body parts, the UA MUST reject the request with a 415 error
response. This could occur if the UA did not understand any of the
top-level body parts within the 'multipart/alternative'.
The handling marking for top-level body parts in a
'multipart/alternative' has no meaning. Therefore, the UA MUST ignore
any 'handling' tags in the top-level body parts of the
'multipart/alternative' body part. Once the UA picks one of the
top-level body parts to use, then the UA MUST use the appropriate
processing rules for the 'handling' tags within the selected top-level
body part.
Rules about the handling parameter are given in Section 8.3. Below, you
suggest to remove Section 8.3 and keep this one instead. The thing is
that we had discussions on the structure of the document and this is the
structure we agreed to have, including having sections like 6,3 for
completeness. At this point, I do not want to reopen that agreement.
Section 8.2
===========
For multipart/alternative, a top-level body type with
'handling=required' makes no sense. By definition, using
multipart/alternative means we expect the UA to not be able to handle
one or more of the body parts - we just do not know which one. I would
remove the note and incorporate the gist into the text:
If the sending UA requires the handling of a 'multipart/alternative'
body as a whole, the UA MUST set the 'handling' parameter of the
'multipart/alternative' body to 'required'. Otherwise, the UA MUST set
the 'handling' parameter to 'optional'. The sending UA MUST set all the
top-level body parts within the 'multipart/alternative' to
'handling=optional'.
the draft already said this. I have added the clarification about
"top-level" body parts.
Section 8.2
===========
For multipart/related, I disagree that if any part is required, the
/related is required.
the text talks about the "root body part", not about the
multipart/related body. The text in the draft already says what you
propose below.
The last sentence is a non-sequitur. Either I
mandate doing something with the 'multipart/related' body or I do not.
I could see, for example, saying that processing the multipart/related
is optional, but if you do process it, one or more of the sub-parts is
required. In this case, the multipart/related is optional, yet one of
the sub-parts is required.
How about:
If the sending UA requires the handling of a 'multipart/related' body
as a whole, the UA MUST set the 'handling' parameter of the
'multipart/related' body to 'required'. Otherwise, the UA MUST set the
handling to 'optional'. The UA sets the 'handling' parameters of the
body parts within the 'multipart/related' body independently from the
'handling' parameter o the 'multipart/related' body. If the sending UA
requires the handling of a particular body, the UA MUST set the
'handling' parameter of that body part 'required'. Otherwise, the UA
MUST set the parameter to 'optional'.
Section 8.2
===========
General: I really do not like the construction "If the UA requires the
handling of foo the UA MUST mark it with 'handling=required'." The
reason I do not like this is this is precisely what RFC 3459 says to
do. All this draft does is repeat what is in that draft. Saying "You
MUST do what you MUST do" seems redundant and error prone.
the feedback we got is that people found this section useful to clarify
what to do in each case.
Section 8.3
===========
This section is redundant with section 6.3. Remove section 8.3, as
section 6.3 talks about processing.
See my comments above about this issue.
Section 8.4
===========
OK, I'll bite: what if I do not feel like returning a 415? Either
enumerate the situation where I MUST return a 415 or enumerate the
situations where I would return something other than 415.
When specifying response codes, we typically use SHOULD because the
request may have some other problem the UAS needs to report using a
different error response. Specifying all those cases would be something
like "go and read RFC 3261" :o)... I think using SHOULD in this context
is clear enough.
Section 9.2
===========
Nit in last line of Note: s/constrain/constraint/
Fixed.
Section 9.4
===========
Since RFC 3459 updated 3204, would not the normative current reference
be to 3459?
both references are listed as normative because the draft also
references the parts of RFC 3204 that deal with signalling transport.
Section 11
==========
I would offer we point out the potential for DoS attacks from complex
MIME bodies. UA's need to be aware of potential stack depth overflow,
line length overflow, pointers to missing content, incorrect
content-lengths, correct content-lengths that span what a parser that
does not look at content-lengths might consider to be content boundaries
with other body parts snuck in.
If you provide me with a reference to a discussion of this attack, I
will be glad to add it to this section. In any case, I will add it to
the next revision of the draft, because I intend to submit 06 in a while.
Thanks for your comments,
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
