[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Hi,
No, I'm not confused about what to send. The fact is that some parts are simply not clear enough. See my inline comments below!
BR/Zacco
-----Original Message-----
From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
Sent: Thursday, February 06, 2003 9:02 PM
To: Lajos.Zaccomer@eth.ericsson.se; mark.a.west@roke.co.uk; abigail.surtees@roke.co.uk; rohc@ietf.org
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Hi Zacco,
It seems you may be confused between a DAP message and its
message-body. Just in case, it is the entire DAP message
(header + CRLF + [body]) that goes through SigComp layer
(both the sending side and the receving side).
Detailed answer below.
Zhigang
> 1. How can endpoint A now if decompression failure occured on
> endpoint B?
It knows if it doesn't receive the uncompressed message retured
from B. Of course, this assumes we don't drop the returned message.
[L.Z.] Explicit notification would be better for testing.We could do it very simply in the verification message that is always sent back.
> Empty message is not good for this purpose, as it
> may be a valid output. For negative tests, it is required to
> know somehow.
There is no empty DAP message, only DAP message with empty
message-body. The message-header is alwasy carried in each DAP message.
See above.
[L.Z.] You misunderstood me. I wanted to say: an empty string output of the UDVM did't mean decompression failure. Of course, it didn't. But it's useless to build a timeout mechanism to check decompression failure, when we have the possibility of an explicit notification. Abbie, this explicit notificatrion is nothing to do with NACK, as it is not part of SigComp but DAP.
> 2. When the uncompressed message is sent back with the same
> header, what length should I use, the original (compressed)
> or the actual (uncompressed) message length?
The DAP receiver simply takes whatever is delivered by the local
SigComp decompressor, check its format and then return it back
without any modifications and without going through the local
sigcomp compressor.
[L.Z.] I asked something else. Abbie had an answer that I already knew: it didn't matter. I expected DAP a simple protocol without having optional things in it. For testing, it would have been favourable. I fear we have to spend long hours with adjusting our DAP versions because of the freedom DAP allows.
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc