Subject: [SIP] Yet some more inconsistencies

From: Peter Kjellerstedt <[email-masked]>
Date: Sun, 06 Aug 2000 14:41:16 +0200

Here are three more inconsistencies I have found in the 2543bis-01
draft:

1) In 3 (SIP Message Overview):

   MIME-Version, Alert-Info and Call-Info are missing from table 3.

2) In 6 (Header Field Definitions):

   According to table 3 Authorization is a request header, and
   WWW-Authenticate is a response header. This also corresponds
   to their respective texts describing them. However, in table 4
   and 5 both Authorization and WWW-Authenticate are listed as
   acceptable in both requests and responses. 

3) In 11.2 (Behavior of SIP User Agents: Callee Issues Response):

   It is stated that the Contact header MAY be present. If I
   am not mistaken this should be changed to MUST for final
   responses to an INVITE.

//Peter

------------------------------------------------------------
Peter Kjellerstedt       E-Mail: [email-masked]
Axis Communications AB   Phone:  +46 46 272 18 69
Scheelevagen 34          Fax:    +46 46 13 61 30
SE-223 63 LUND           URL:    http://www.axis.com/

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 06 Aug 2000 11:03:44 -0400

>    MIME-Version, Alert-Info and Call-Info are missing from table 3.

Added (these headers were tentatively added, pending WG consensus).

>    acceptable in both requests and responses.

This raises a larger issue, namely response authentication. One
possibility which was discussed during the IETF meeting was to
transition to MIME-based security, using S/MIME (RFC 2311) or MIME-PGP
(RFC 2015). In that mode, both requests and responses can be treated the
same. However, since SIP needs to sign and encrypt headers as well as
message bodies, you end up with something like

     INVITE ...
     From:  ...
     To: ...
     Mime-Version: 1.0
     Content-Type: multipart/encrypted; boundary=foo;
        protocol="application/pgp-encrypted"

     --foo
     Content-Type: application/pgp-encrypted

     Version: 1

     --foo
     Content-Type: application/octet-stream

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.2

     [some encrypted message]
     -----END PGP MESSAGE-----

where [some encrypted message] would be again a SIP message. From what I
can tell, the data to be encrypted looks something like

Content-Type: message/sip

INVITE ...
repeating all important headers

[SDP] body

For basic and digest, authorization makes sense both ways and should be
symmetric. This clearly needs to be fleshed out; I doubt that anybody
actually implements response authorization at this point.

>    am not mistaken this should be changed to MUST for final

Fixed.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs