Subject: [Simple] 501 Not Implemented considered harmful in MSRP

From: "Jussi K. Virtanen" <[email-masked]>
Date: Sat, 04 Feb 2006 17:32:57 +0200

Hi,

MSRP defines the status code 501 Not Implemented to be sent as a
response to a request with unknown request method. I propose that
the status code is removed and the status code 400 Bad Request is
used instead.

The existence of 501 Not Implemented implies that it is acceptable
to introduce new capabilities (in this case, a new request method)
to a session outside an offer--answer exchange. As far as I can see,
this is in conflict with established conventions in SIP and SDP.

Best Regards,

--
Jussi K. Virtanen

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Feb 2006 16:25:12 -0800

I guess I could go either way on this - I probably need to think about it
more. More information about what went wrong is often better.

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 14 Feb 2006 13:33:52 +0100

You can extend MSRP with new methods. We however do not negotiate 
supported MSRP methods in the offer/answer exchange when initiating the 
request. Therefore 501 is needed. I don't understand why 400 is better 
in this case.

The draft says

"A 501 response indicates that the recipient does not understand the
    request method."

Regards,
Hisham

---

From: "Jussi K. Virtanen" <[email-masked]>
Date: Thu, 16 Feb 2006 09:34:33 +0200

Hi,

On 2006-02-14, Hisham Khartabil <[email-masked]> wrote:
> You can extend MSRP with new methods. We however do not
> negotiate supported MSRP methods in the offer/answer exchange
> when initiating the request. Therefore 501 is needed. I don't
> understand why 400 is better in this case.

RFC 3261 "SIP: Session Initiation Protocol":

  "SIP supports five facets of establishing and terminating
   multimedia communications:

      -- --

      User capabilities: determination of the media and media
           parameters to be used;

      -- --

      Session management: including transfer and termination
           of sessions, modifying session parameters, and
           invoking services."

Why should MSRP implement a lacklustre detour on something that
is SIP's forte?

In my opinion, MSRP should explicitly promote the negotiation
of all extensions, some of which may introduce new request
methods, via an offer--answer exchange, because the introduction
of such an extension is a disruptive change---there's a chance
that the other endpoint is unable to support it.

Thus, the rationale behind my proposition to use the status code
400 for an unknown request method is to make it clear that it's
unacceptable to bypass session control when making disruptive
changes to a medium.

BR,

--
Jussi K. Virtanen

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Feb 2006 15:38:04 +0200

> that the other endpoint is unable to support it.

I don't agree; the protocols that SIP and SDP set up may have plenty of 
details that the endpoints work out once the session is already agreed. 
For example, comedia-tls doesn't need to specify cipher suites or 
compression algorithms for the TLS session, because the correct place 
for those is in the TLS handshake.

> unacceptable to bypass session control when making disruptive

I think 5xx will work just as well. I think what you might actually be 
asking for is a way to do specific negotiation of features up front, in 
MSRP. Something like a server HELLO message that lists the 
allowed/supported methods that could actually be a different set 
depending on the configuration of the state machine, e.g., pre AUTH vs. 
after.

Cheers,
Aki

---

From: "Jussi K. Virtanen" <[email-masked]>
Date: Tue, 21 Feb 2006 08:57:03 +0200

Hi,

On 2006-02-20, Aki Niemi <[email-masked]> wrote:
> I don't agree; the protocols that SIP and SDP set up may have
> plenty of details that the endpoints work out once the session
> is already agreed. For example, comedia-tls doesn't need to
> specify cipher suites or compression algorithms for the TLS
> session, because the correct place for those is in the TLS
> handshake.

I have a few gripes with your example. First, TLS was not
initially designed with multimedia sessions in mind, unlike MSRP.
Secondly, the TLS handshake is somewhat analogous to the
authentication procedure in msrp-relays: both protocol entities
are aware of its coming.

> I think 5xx will work just as well. I think what you might
> actually be asking for is a way to do specific negotiation of
> features up front, in MSRP. Something like a server HELLO
> message that lists the allowed/supported methods that could
> actually be a different set depending on the configuration of
> the state machine, e.g., pre AUTH vs. after.

Why to reinvent the wheel? Wouldn't such a negotiation belong to
session control? It could be based on, for example,

  a=methods:FOO BAR

or something similar in SDP for request methods (beyond SEND and
REPORT) that an endpoint either accepts or intends to utilise
during a session.

501 makes sense in HTTP and SIP: in those protocols, the initial
point of contact between a client and a server is a request. In
MSRP, however, the initial point of contact is the offer--answer
exchange. As I have stated earlier, my belief is that after the
negotiation the endpoints should have a definite agreement of
each other's capabilities so that disruptive changes cannot
occur unless session control, based on SIP and SDP, is involved.

BR,

--
Jussi K. Virtanen

---

From: Ben Campbell <[email-masked]>
Date: Thu, 23 Feb 2006 15:31:14 -0600

Hi,

I don't have a new argument to add to this either way.

However, the idea of having explicit extension negotiation for MSRP  
has been considered on several occasions by the wg. What we have now  
was a result of that consensus, with the caveat that if someone  
introduces a new extension that requires more explicit negotiation,  
then that someone would also need to specify a way to signal or  
negotiate that extension; assumedly at the SDP level.

Thanks!

Ben.