A couple more thoughts on "semantically identical"

["Paul Francis" <yoid2000@home.com>]

Sorry to come back to this topic...I know we need to get off of talking
about terminology and start talking about technology, but...

It occurs to me that in not liking the phrase "semantically identical", I
was focusing on the wrong word...that is to say, the problem is not in the
word "semantic" but in the word "identical".

My thinking had been that, if you've got an application that is working just
fine (voice over gehco) and is robust (to changes in the decompressor due to
mobility), then at a high level the "semantics" are working just fine.
Therefore I thought we must not be interpreting the word "semantic" well.

Strictly speaking, though, I suppose that if compression really does
occasionally mess up the RTP sequence number or the IP-ID, then by the
letter of the law the result is not semantically identical, even if no
application is hurt by it.

So I want to ask the following question to the group.  Say a middlebox is
tweaking TCP sequence numbers so that it consistently adds 1 to every
sequence number throughout the whole connection.  Is this semantically
identical?  I would argue that it is, because the semantics of the TCP
sequence number is "offset from the first sequence number", and in fact in
this particular scenario every sequence number received by the destination
does accurately represent the true offset.

If people out there agree that this is semantically identical, then I think
we have a very strange situation.  Which is to say that none of us would
agree with actually transposing TCP sequence numbers in a compressor because
it would not be robust (with mobility).  Yet at least some of us would
consider doing it for RTP, because the application can robustly survive a
small amount of error.

In other words, I would not consider non-transparent TCP compression which
in theory could be made semantically identical, and yet would consider gehco
compression which, from a strict interpretation of the header field
semantics (as opposed to the application semantics), is not semantically
identical.

Once again, I come to the conclusion that the phrase "semantically
identical" is fraught with peril.

Anyway, getting back to my original point that the problem word is not
"semantic" but rather "identical", I realized that what I really think the
phrase needs to be is "semantically good enough"!  This of course gets back
to the pliant/brittle distinction I was trying to get at earlier.  RTP is
somewhat pliant, so one can get away with "semantically good enough",
whereas with TCP you can't.

PF

ps.  Still plan to take another whack at the requirements in a day or two
here...