Subject: [Simple] message-sessions-05

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Apr 2004 14:45:51 -0400

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?

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.

	Paul

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