[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] RE: DAP issues
Hi,
If it is the decompressed message that should be sent back uncompressed then it's all right. It needs a little clarification in the doc. I e.g. thought it was the SigComp message that should be sent back.
I agree, let's keep it simple. That is why even the least possibility of having dead lock should be removed! If we all agree that a response should not be asked in case of a response, let's have it specified in the doc! Including the received header also unnecessarily complicates the DAP logic. I think the header should not be included! Is there a special reason to have it? If not let's keep it simple!
It is VERY IMPORTANT regarding the very short available time that there will be no interoperability problems with DAP. It should be STRICT with NO MAY in the specification, only MUST!
BR/Zacco
-----Original Message-----
From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]
Sent: Thursday, January 30, 2003 6:54 PM
To: 'Lajos Zaccomer (ETH)'; 'rohc@ietf.org'
Cc: 'zhigang.c.liu@nokia.com'; 'Adam Roach'
Subject: RE: DAP issues
Hi all,
>The discussions on DAP should be ended this week as the SIPit
>is very close. All the participants that intend using DAP
>should accept a last version that should be available at
>latest on Monday morning. The accepted version should be used
>by the participants of SIPit.
This sounds reasonable to me.
>
>I have the following modification and extention proposals:
>
<snip - moved to bottom>
>
>* need-response should have values: ("ANY" / "PREV" / "NO")
> - ANY: implementation choice
> - PREV: send back the previously uncompressed message
>of the compartment
> (This is very useful for testing if the message
>was decompressed correctly, as the other endpoint does not
>know what I sent.)
> - NO: need no response
>
I think it is still defined in DAP to echo the received message back to the sender, uncompressed, so there isn't any need to recompress it and send it back for checking purposes. Consequently the TRUE/FALSE corresponds to ANY/NO and is sufficient for our testing at the moment. (ANY could be equivalent to PREV, depending upon the configuration of the decompressor)
>* the header should not be arbitrary in case of a response. It
>should not be allowed to ask for a response in this case. It
>is most favourable that the message flow may be entirely
>controlled by one of the endpoints!
>
I think that it makes sense for the receiver not to ask for a response so that the sending end is in control of the flow but I don't think it needs to be specified in DAP. The receiver can just never set the response field to TRUE and the sender should ignore this field.
>* parameterization of compartment create:
>this line is processed only if line-6 brings CREATE
>line-6a = "state-memory-size" ":" *DIGIT CRLF
>if there is no parameter, the application on its own may
>choose a state memory size
>(it might be line-7 or whatever with shifting the other lines)
>
>* There should be another line to start/stop the dispatcher.
>Reason: there are tests even amongst the torture testst that
>use non-default values, and it is favourable to test all
>possible situations.
>
I believe that there is only one torture test now that doesn't run in 2K of memory and that it can be modified to run in 2K.
>line-x = "dispatcher-op" ":" ( "START" / "STOP" );
>line-y = "dispatcher-params" ":" *DIGIT ":" *DIGIT ":" *DIGIT
>(may be inserted somewhere before the body line)
>The three parameters - each of which are optional - are the
>cpb, dms and sms values for the dispatcher, respectively. If
>any of them is not specified or invalid, the application may
>choose a valid value instead.
>
I think that in both these cases there may be some merit in defining them in the future but that for the moment we have sufficient for a first face-to-face testing event.
As it is defined a SigComp decompressor would not expect to have to change these parameters on the fly so to do it would bring extra implementation. It would also need more definition than this due to the fact that some of these are endpoint actions rather than compartment actions. If an endpoint were connected to 2 peers and one sent a dispatcher-op : STOP message, what would happen to the connection to the other peer?...
I think (correct me if I'm wrong) that for the first testing event we want a simple protocol that we can ascertain quickly is doing what we expect so that we can concentrate on the SigComp testing itself. Then if we want to do more testing or possibly remote testing we could define some of these actions, later.
Best regards,
Abbie,
>With these modifications a whole series of tests may be run
>automatically.
>
>Please, consider the above issues and comment them!
>
>BR/Zacco
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc