I have some points regarding handling odd combinations of Content-Type and
Content-Disposition where I feel I need some clarification. Where I can I have
indicated what I
think the answer should be, but I am not confident of these answers.
1) What should a UAS do if it receives a request where the disp-type in a
Content-Disposition header is inconsistent with the Content-Type. (What I mean by
inconsistent is
that the UAS understands the disp-type and understands the content type, but doesn't
know how to dispose of that content in that way.) For instance:
Content-Type: Application/SDP
Content-Disposition: icon
If the handling is optional and the UA is being lenient, then it may make sense to
ignore this. But if it is required then the UA can't honor the disposition and so
should return an error. But what error? None of the plausible candidates (406, 415,
488, 606) seem quite right. That only seems to leave 400.
2) What should a UAC do if it receives a response with the same problem?
In the cases above where ignoring the problem was ok it probably is here too. When
an error is required and this was an invite, I guess must send the ack and then a BYE
with a reason.
When it was not an invite, can anything be done other than ignore?
3) What should happen (in UAS or UAC) if handling=required but disp-type is unknown?
I think the answers in 1 & 2 apply here as well.
4) Suppose a body has content type Multipart/mixed:
4a) what should the disp-type of the content disposition be?
None of the values defined in bis-09 seem appropriate. One answer would be to say
that when the content type is multipart the disp-type is irrelevant, but that seems
wrong. Bis-09 does use "attachment" in some examples. Perhaps that should be used for
all composite-types.
The spec says that when there is no Content-Disposition then the disp-type
defaults to "session" if the Content-Type is application/sdp, and otherwise to
"render". So I
suppose it also ought to be ok to explicitly use "render", even though it seems wrong.
4b) what should happen if there are multiple parts with the same disp-type?
This seems to depend on whether multiples can be used, and this varies with the
disp-type. For "session" it doesn't make sense to have more than one. For "render"
multiples are probably ok. For "alert" and "icon" the ability to support multiples may
be UA specific.
If multiples can't be handled, but at most one has handling=required, then the
extras can be ignored. But if more than one has handling=required then this probably
ought to be an error. Exactly what error is unclear - possibly the same as for
question 1.
4c) is there any current use (in sip bodies) for Multipart subtypes other than mixed
and signed? Should other types be rejected?
I don't think there are, and 415 seems like the proper response if they are used.
Paul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
