Subject: RE: [Simple] message-sessions-05

From: "Chris Boulton" <[email-masked]>
Date: Wed, 14 Apr 2004 09:27:50 +0100

>
>Ben,
>
>A few comments on the latest version. (I have been following the
>discussion on DSRs, but I just haven't had time to carefully think thru
>the issues, so no comment on the major issues of that right now.)
>
>I've recently been looking into generalized mime support in sip. As a
>result of that, I have concluded that its ugly to special case the mime
>headers in each protocol that embeds mime bodies. Doing so just
>complicates the code.
>
>So I think we should be careful to ensure that mime headers are handled
>compatibly in the enclosing protocol and in mime. There are a couple of
>implications here:
>
>- we ought to make the syntax of Content-Type identical to what it is
in
>mime, either by copying or by reference. Currently it is the same,
>except that msrp doesn't define "token" at all.
>
>- there should be provision for other mime entity headers. (I know this
>is already on the to-do list.)
>
>Both of these can be covered by normatively referencing the definition
>of entity-headers from RFC 2045. To avoid confusion, msrp can either
>simply adopt the definition of token from 2045 for all purposes. Or it
>can provide its own definition of token but call it something else so
>its syntax can coexist with that of 2045.
>
>(Note that there is currently an inconsistency between 3261 and 2045
>because they use different definitions of token. 2045 is less
>restrictive, so there could be some valid mime content-type headers
that
>are not valid as sip content-type headers. The 2045 definition of token
>permits !#$&^{|} in addition to everything 3261 permits. Apparently it
>hasn't been a problem so far, but we might as well avoid that
>inconsistency in msrp.)
>
>Nit: in the definition of header:
>
>        header       = Tran-ID / Session-URL / Content-Types /
>                       From / To / Message-Receipt / Receipt-ID /
>                       Byte-Range
>
>Content-Types should be Content-Type.
>
>Nit: in the following:
>
>        receipt-type		   = "receipt-type" "=" alt-receipt-type
>
>wouldn't it be simpler to just say
>
>        receipt-type		   = "receipt-type" "=" media-type
>
>(from the definition of Content-Type) and avoid all the redundant
>definitions?

[Chris Boulton] Done Paul.

>
>Receipt-Type negotiation: Seems bad to have to accept a receipt as a
>regular message in order to negotiate it as an alternate receipt type.
>Seems better to just let receipt-type be a request for a different type
>that can be honored or not, with the default type being always
acceptable.

[Chris Boulton] mmmmm - not convinced.  Doesn't this all depend on the
importance placed on receiving the receipt?  It could be critical for me
to know it has been delivered.  If an alternative receipt type is
specified it must be one that was specified in the offer-answer
exchange.  If, for some reason the far end can not create the receipt
due to this type, it should kick back with an appropriate error
response.  If a relay was involved, it could generate a negative receipt
on the endpoints behalf.

>
>	Paul
>
>
>_______________________________________________
>Simple mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/simple

This message has been scanned for viruses by MailControl - www.mailcontrol.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple