Gonzalo - comments inline. This is looking good.
Paul
Gonzalo Camarillo wrote:
Hi Paul,
thanks for your comments. Answers inline:
Paul Kyzivat wrote:
Gonzalo,
Thank you for doing this. It is a great start. I largely agree with
what you have written.
One specific comment about the draft:
- Open issue in section 3: perhaps a new Reason code, to be used
with a 415 response would be adequate.
what do you mean by a reason code? Do you mean a Warning code?...
because Reason header fields are not allowed in responses.
Never mind. I just wasn't thinking.
I have added more structure to the draft (i.e., a few new sections) that
I believe make it easier to read. You can fetch a working version from:
http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt
I believe you have covered my concerns.
I've been thinking if there are other similar issues regarding
references to body parts. I think another is that it can be possible for
a reference to be present in a body part. (For example if one body part
is an application/sipfrag.) Potentially the reference could then be in
an optional part that is not understood by the recipient. Again, we
wouldn't want processing to depend on whether a reference was processed
or not.
I'm not convinced there are any cases where this can be a real issue. It
wouldn't be if the referenced body part were "within" the body part
containing the reference. I think the sipfrag case would always fall
into this category. I don't have any other examples in mind, so maybe
this isn't really an issue. I'd just rather find any now rather than
later. Can anybody else think of anything in this category? (Or do I
have a monopoly on that job?)
Re Issues:
OPEN ISSUE 1: do we need to say something about other types? Related
(rfc2387), parallel, digest, external-body.
I don't know much about these. I quickly scanned 2387 and see that it
has some special rules re processing Content-Disposition of the
contained (related) parts. I *think* those are consistent with what we
are doing.
OPEN ISSUE 2: we know that we do not want two SDPs in a 'multipart/
alternative', but is this valid generally with any content type?
Would it be possible to provide two alternative body parts using the
same format and, thus, the same content type but in, say, different
languages?
Its my understanding that the distinction is based on which can be
understood, relative to Content-Type. It isn't apparent to me that
making this decision based on other attributes is valid. For one thing
the parts are supposed to be ordered by increasing richness. If they
differed by language this wouldn't be true.
So I think what you have is ok.
OPEN ISSUE 3: do we need to talk about encrypted body parts?
???
OPEN ISSUE 4: the handling parameter is a Content-Disposition
parameter. Therefore, in order to set the handling parameter, it is
necessary to provide the 'multipart' body with a disposition type.
Otherwise, its disposition type would be, by default, render. Which
disposition type shall we use for 'multipart/mixed' bodies? Shall we
create a new disposition type for this purpose?
I think we need a new disposition type. I also think we should specify
that this new one is the default for bodies of multipart/* content-type.
That should fix up most examples and prior use, which afaict have not
specified a content-disposition.
OPEN ISSUE 5: we could define a new response code (Content or
Disposition Type not Supported in this Context) to report known
content and disposition types appearing in an unsupported context in
order to be more explicit than always using 415. It would avoid
receiving a 415 response with an Accept header field containing all
the content types used in the request. How useful would this really
be?
I'm inclined to say yes for completeness. But I don't expect to see any
implementations using this the change their behavior at runtime.
Another thing in Section 3: You have used SHOULD in this section. I
thought we wanted to change this to MUST. Did we?
There are also a couple of typos in Section 3:
s/extensions relay on them/extensions rely on them/
s/miltipart/multipart/
That's it for now,
Paul
_______________________________________________
Sip mailing list https://www1.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
