[rohc] RE: DAP issues

["Surtees, Abigail" <abigail.surtees@roke.co.uk>]

Hi Zacco,

>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 think Zhigang clarified it in his mail on Tues, but we could add the following
line to section 2, paragraph 2.

"The entire DAP message (message-header + CRLF + message-body)
is returned. This allows the sender to compare what it sent with what the
receiver decompressed."

>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! 

I've just reread this section of DAP 1b and there does seem to be an issue with
this that we must nail down.

Either
(as it states in DAP 1b) the receiver can set the need-response field to TRUE and 
both sender and receiver control the flow, allowing the possibility of infinite sending
(fixed by one end setting the field to FALSE)
or
(as I suggested in my last mail) the sender is in control of the message flow, the
receiver must NOT set the flag to TRUE. 

One thing to take into account is whether either approach will enable/prevent specific
test patterns.  The latter seems simpler to me, and I don't think it prevents anything.  
What does anyone else think?

>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!

I'm not sure which header you are talking about here.  My understanding 
(again, correct me if I'm wrong) is that in the case where the sender asks
for a response we get:

sender							receiver
  ----------SigComp DAP_message_ 1(requesting response)-----> 

  <---------DAP_message_1 in clear text----------------------------------

  <---------SigComp DAP_message_2(no response)------------------

The body part of DAP_message_2 COULD be a copy of the body
part of DAP_message_1 if the receiver so chooses but it would have
to put its own DAP header on it so that the sender knows to which
compartment and endpoint it belongs and whether to accept or reject
it (the main reasons for DAP in the first place).

>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!
>
Agreed.

Best regards,

Abbie

>BR/Zacco
>
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc