Hi Paul,
I have addressed your comments and include them in revision 01 before
submitting it to the IETF. I will now go ahead submit it so that it
appears in the official repository. Until then, you can fetch it from
the same link as before (reload the page if you downloaded it before):
http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt
inline:
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?)
I wrote the text thinking of that possibility, but now I have rephrased
it so that it is even more explicit about the fact that references can
be found in body parts.
I have added the following text pointing to an example of such a case:
"In another example, the extension for file transfer in SDP
[I-D.ietf-mmusic-file-transfer-mech] places a Content-ID URL in a
'file-icon' SDP attribute. This Content-ID URL points to a body part
whose disposition type is supposed to be 'icon'."
I have also added the following new open issue about the need to parse
all body parts before being able to process any of them:
"4.2. Body Processing
UAs process message bodies and body parts in the following way. On
receiving a SIP message, if a body part is not referenced in any way
(e.g., there are no header fields or other body parts with a
Content-ID URL pointing to it), the UA processes the body part as
indicated by its disposition type and the context in which the body
part was received.
OPEN ISSUE 4: this means that a UA would need to parse all body parts
to find references between them before being able to fully process
them. If we are OK with this, we need to include text here
explaining it."
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.
I have added the following text to Section 5:
"This specification recommends support for 'multipart/mixed' and
'multipart/alternative'. At present, there are no SIP extensions
that use different 'multipart' subtypes such as parallel [RFC2046],
digest [RFC2046], or related [RFC2387]. If such extensions were to
be defined in the future, their authors would need to make sure
(e.g., by using an option-tag or by other means) that entities
receiving those 'multipart' subtypes were able to process them. As
stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/
mixed'."
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.
I double check with an email expert to make sure we get this right.
OPEN ISSUE 3: do we need to talk about encrypted body parts?
???
Christer brought this one up. What did you have in mind?
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.
This is probably something email people did not face. I think it makes
sense to define the new disposition type.
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.
yes, I am leaning towards defining it as well.
Another thing in Section 3: You have used SHOULD in this section. I
thought we wanted to change this to MUST. Did we?
You refer to the following statement, right?
"In particular, UAs SHOULD support the 'multipart/mixed'
and 'multipart/alternative' MIME types."
If people agree that this should be a MUST, I will be happy to change it.
There are also a couple of typos in Section 3:
s/extensions relay on them/extensions rely on them/
Fixed.
s/miltipart/multipart/
Fixed.
Thanks,
Gonzalo
_______________________________________________
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
