Subject: Re: [BEHAVE] How to handle an unsupported class of a known STUN method?

From: Philip Matthews <[email-masked]>
Date: Mon, 1 Sep 2008 12:47:21 -0400

On Thu, 28-Aug-08, at 19:46 , Cullen Jennings wrote:

>
> I'm don't see  what the issue is here. It seems like any  
> specification that defined a new method would have to say what  
> happened for all classes of that method. Any use of a class that was  
> not specified for a method would be invalid to send.

I totally agree that it should be invalid to send. But sometimes these  
things happen anyway so a receiver must be robust against receiving  
such.

Let's look at two concrete examples:
a) TURN-10 will define a Send request/response transaction. But up  
until this point, it was invalid for a client to send a Send request;  
only the Send indication was defined. So what should a server  
compliant with TURN-09 do when it received a Send request??
b) In TURN-10, Data request/response transactions will still be  
undefined. So what should a client do if it receives a Data request??

My proposal (see below) is to say that, if received, these messages  
are silently ignored (rather than, for example, causing a 400 Bad  
Request response).

- Philip

>
>
> On Aug 13, 2008, at 5:39 , Philip Matthews wrote:
>
>> In section 7.3, draft-iet-behave-rfc3489bis-18 states that when a  
>> received STUN message with an unknown method is received, the  
>> message is silently discarded. However, it does not define how to  
>> handle a receive message with a known method when the class is  
>> unsupported; for example, an Allocate indication or a Data request,  
>> to give two examples from TURN.
>>
>> I propose that this be clarified to say that the message is  
>> silently ignored in this case.
>>
>> An alternative would be to silently ignore an unsupported  
>> indication, but to return 400 Bad Request for an unsupported  
>> request. However, this would mean that clients would have to be  
>> able to return error responses, and Rohan has previously objected  
>> to clients having to implement any sort of server-side processing.
>>
>> - Philip
>>
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>
>

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave