From rohc-bounces@ietf.org Fri Oct 1 03:20:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01255 for ; Fri, 1 Oct 2004 03:20:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDHlN-0007mY-4Z for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 03:23:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDHXY-0005Pm-AA; Fri, 01 Oct 2004 03:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDHNq-0003CP-MQ for rohc@megatron.ietf.org; Fri, 01 Oct 2004 02:59:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28994 for ; Fri, 1 Oct 2004 02:59:12 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDHWE-0007S4-F7 for rohc@ietf.org; Fri, 01 Oct 2004 03:07:55 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i915wFLh013773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Oct 2004 07:58:15 +0200 Message-ID: <415D005A.6050001@effnet.com> Date: Fri, 01 Oct 2004 08:59:38 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2115@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2115@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org, "'Ghyslain Pelletier \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Hi, since this discussion seems to deteriorate into religious warfare, let me suggest a compromise. If I have managed to misunderstand the points of conflict after 100s of mail of the subject, please do hit me over the head with a mail swarm and I'll butt out of this issue forever. We have all agreed that the annotations don't actually have a normative meaning so why not do the following: - Relax the text around them to clearly show that this is actually just a comment and does not mean anything formal. - Remove all mention of tools. If someone wants to write parsers or use tools, then fine, but why mention it in the specification? If a profile writer happens to abuse these for some reason, they are still just comments. - Rename them from Annotations to "Field Width Comments" to emphasize that these are COMMENTS Can Ghyslain agree on keeping them then? And also, can Carsten and Robert agree to this kind of reduction of them? My suggestion for a replacement text is the following: 4.7 Comments Comments do not affect the formal meaning of what is notated, but can be used to improve readability. Their use is optional. ................ 4.7.3 Field Width Comments A special type of comment that can be used to help the reader interpret packet formats is bitfield width comments. As all comments, these have no formal meaning, but normally only appears immediately after a field name. These comments use a "[" and "]" as delimiters. Enclosed within these brackets, a number indicating the width of the preceding field should be written. For example: uncompressed_format = discriminator [ 8 ], tcp.seq_number [ 32 ], tcp.flags.ecn [ 2 ], Can they really offend anyone now? If the problem is the use of brackets, then the same person should also be offended by the fact that we can have both "%" and "/* ... */" comments. And this does in no way stop the use of parsing tools. /Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 03:54:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03467 for ; Fri, 1 Oct 2004 03:54:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDINJ-0000Wv-AX for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 04:02:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDHsh-0002zj-MY; Fri, 01 Oct 2004 03:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDHnC-0001FZ-24 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 03:25:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01632 for ; Fri, 1 Oct 2004 03:25:24 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDHvQ-0008Bg-5t for rohc@ietf.org; Fri, 01 Oct 2004 03:34:07 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i917PCWR012915 for ; Fri, 1 Oct 2004 09:25:12 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 09:25:12 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 09:25:12 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: rohc@ietf.org Date: Fri, 1 Oct 2004 09:25:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 07:25:12.0877 (UTC) FILETIME=[CA3F0DD0:01C4A787] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [rohc] FN designed for tools, or vice versa? X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d > ]Argh. I totally agree that tools are helpful. > ]My point is that they don't belong to specs! > ]So the stuff needed for tools can and should be left for the > input to ]the > tools or coded in the tools themselves. > > Ah, OK, so is the sticking point this: > > That you think it is possible to have tools without the > spec providing the syntax they need to work on, whereas > I (and I assume Carsten) don't? I think we should do our best not to let the use of tools affect the specification, that must be the last alternative and only used when really needed. I am not sure about annotations, but I still have not seen any convincing argument why we would need to define anything like the "external method" thing. What worries me with this discussion is that there is not even a clear view of what an "external method" would be. As with annotations, we seem to be discussing a moving target. As written in the current FN, it was actually anything defined outside of the FN, while we have also ideas saying it is anything defined outside FN/FN-spec, or any method not defined formally in FN/FN-Spec. I am still waiting for an answer from Carsten regarding formal methods defined in an FN-spec. I believe that should be the "normal" way to extend the FN for new profiles. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 03:56:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03737 for ; Fri, 1 Oct 2004 03:56:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIPx-0000bt-LX for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 04:05:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIFa-0002Au-8e; Fri, 01 Oct 2004 03:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDHxt-00044T-L7 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 03:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02170 for ; Fri, 1 Oct 2004 03:36:28 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDI67-0008Mj-Pa for rohc@ietf.org; Fri, 01 Oct 2004 03:45:11 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i917aGRU016899 for ; Fri, 1 Oct 2004 09:36:16 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 09:36:16 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 09:36:16 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Finking, Robert'" , "'Carsten Bormann'" Date: Fri, 1 Oct 2004 09:36:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 07:36:16.0774 (UTC) FILETIME=[55F5B260:01C4A789] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: rohc@ietf.org Subject: [rohc] FN as humour X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Robert, > ]> Yes, the writer will, but not necessarily the reader. > ]> Supposing the writer has definitions in his head for all > ]> three methods, but that in a deadline rush, he accidentally > ]> forgets to specify the definition of method_c in the profile. > ]> Then he goes on holiday or is busy/uncontactable/dead for a > ]> couple of months. > ]> > ]> The implementer comes along and gets back these three > ]> undefined methods, but only sees definitions for two of them. > ]> He has no clue as to whether the third method should have a > ]> definition in the FN, or whether there is a normative > ]> definition in an RFC somewhere. > ] > ]First I thought this was some kind of joke... > ] > ]What about if there was an earthquake? > ]If we reach the end of the world, how do we make sure > ]our specifications gets published un an unambiguous way > ]even after that? > > =) I try to mix a bit of humour into my posts as arguing all > day can put you in a bad frame of mind =) Still the point I > was trying to make was not a joke. I hope this mix of humour > and content is not a problem? Please say if it is, and I'll > try to stop =) That is fine, I we are all fine with and appreciate humour, as well as rather direct and sometimes *hard* discussions. However, I could not see and can not see anything but humour in that example. If a method is missing, there is obviously an error in the FN-based specification, independent what was the intention by the writer (define it himself in FN-form or english, refer to the (an) FN, or refer to some other document). > ]Seriously, an FN-based specification would either define > ]methods itself or use methods from another specification > ]which it refers to. That is how specifications are built. > ] > Right, sure so methods it defines its self or methods defined > in the FN are ordinary "internal" methods. The ones defined > in another specification are "external" methods. If you > don't provide any syntactic distinction between the two, > the reader of the profile has no way of distinguishing > between an error the profile writer has made and a > legitimate external reference. Of course he can. If it is defined somewhere else, there will be a reference to that place. Without a reference, it is actually an undefined method, and it is an error in the spec. > ]I do not know what you mean by writer, if you mean a profile > ]writer, neither do I know what you mean by a reader. > > OK what I mean by a writer is somebody like Mark, who > produces packet formats described in the notation, which > somebody like me (the reader) will have to use to produce > an implementation. And you need all formats specified with defined methods, independent of where they are defined you need the reference. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 03:57:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03808 for ; Fri, 1 Oct 2004 03:57:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIQh-0000eD-4U for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 04:06:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIFc-0002EH-T7; Fri, 01 Oct 2004 03:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIA7-0007av-Bd for rohc@megatron.ietf.org; Fri, 01 Oct 2004 03:49:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02926 for ; Fri, 1 Oct 2004 03:49:06 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIIW-0000BS-Tu for rohc@ietf.org; Fri, 01 Oct 2004 03:57:49 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 08:49:16 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2119@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Kristofer Sandlund'" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 08:49:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Carsten Bormann , rohc@ietf.org, "'Ghyslain Pelletier \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 I'd be happy to settle for that. Thanks for mediating =) -----Original Message----- From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] Sent: Friday, October 01, 2004 8:00 AM To: Finking, Robert Cc: 'Ghyslain Pelletier (LU/EAB)'; rohc@ietf.org; Carsten Bormann Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Hi, since this discussion seems to deteriorate into religious warfare, let me suggest a compromise. If I have managed to misunderstand the points of conflict after 100s of mail of the subject, please do hit me over the head with a mail swarm and I'll butt out of this issue forever. We have all agreed that the annotations don't actually have a normative meaning so why not do the following: - Relax the text around them to clearly show that this is actually just a comment and does not mean anything formal. - Remove all mention of tools. If someone wants to write parsers or use tools, then fine, but why mention it in the specification? If a profile writer happens to abuse these for some reason, they are still just comments. - Rename them from Annotations to "Field Width Comments" to emphasize that these are COMMENTS Can Ghyslain agree on keeping them then? And also, can Carsten and Robert agree to this kind of reduction of them? My suggestion for a replacement text is the following: 4.7 Comments Comments do not affect the formal meaning of what is notated, but can be used to improve readability. Their use is optional. ................ 4.7.3 Field Width Comments A special type of comment that can be used to help the reader interpret packet formats is bitfield width comments. As all comments, these have no formal meaning, but normally only appears immediately after a field name. These comments use a "[" and "]" as delimiters. Enclosed within these brackets, a number indicating the width of the preceding field should be written. For example: uncompressed_format = discriminator [ 8 ], tcp.seq_number [ 32 ], tcp.flags.ecn [ 2 ], Can they really offend anyone now? If the problem is the use of brackets, then the same person should also be offended by the fact that we can have both "%" and "/* ... */" comments. And this does in no way stop the use of parsing tools. /Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 04:01:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04083 for ; Fri, 1 Oct 2004 04:01:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIUS-0000im-BK for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 04:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIG1-0002F4-1B; Fri, 01 Oct 2004 03:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIB9-0008Rs-Kl for rohc@megatron.ietf.org; Fri, 01 Oct 2004 03:50:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03000 for ; Fri, 1 Oct 2004 03:50:10 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIJP-0000DF-74 for rohc@ietf.org; Fri, 01 Oct 2004 03:58:53 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i917ngno014094; Fri, 1 Oct 2004 09:49:44 +0200 (MEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73B46C9A-137E-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: External Encoding Methods (was: RE: ROHC-FN Snapsh ot - Wednes day's update) Date: Fri, 1 Oct 2004 09:49:41 +0200 To: "Lars-Erik Jonsson (LU/EAB)" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'Finking, Robert'" , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit On Sep 30 2004, at 17:01 Uhr, Lars-Erik Jonsson (LU/EAB) wrote: > What I have thought all the time was that: > > An encoding method is > -- either defined in english (in the FN draft or in the > draft giving the FN spec) > -- or defined in FN, i.e. by giving an FN structure that > defines the encoding method in terms of other encoding > methods, field lists, and let-expressions (in the FN > draft or in the draft giving the FN spec) This is exactly my view. (So far, the FN draft does not define any methods in FN, IIRC, but it certainly can.) > I have not heard anyone saying that an FN spec can not > define its own methods formally. Actually, the *only* thing an FN spec can do is define encoding methods formally. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 04:28:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05542 for ; Fri, 1 Oct 2004 04:28:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIuH-0001DD-H7 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 04:36:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIdm-0008Hg-1v; Fri, 01 Oct 2004 04:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDILi-0004HQ-F6 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 04:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04070 for ; Fri, 1 Oct 2004 04:01:05 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDITw-0000i9-Uk for rohc@ietf.org; Fri, 01 Oct 2004 04:09:48 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9180rRU026061 for ; Fri, 1 Oct 2004 10:00:53 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 10:00:53 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 10:00:53 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 10:00:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 08:00:53.0727 (UTC) FILETIME=[C64AD6F0:01C4A78C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "'Finking, Robert'" , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > > What I have thought all the time was that: > > > > An encoding method is > > -- either defined in English (in the FN draft or in the > > draft giving the FN spec) > > -- or defined in FN, i.e. by giving an FN structure that > > defines the encoding method in terms of other encoding > > methods, field lists, and let-expressions (in the FN > > draft or in the draft giving the FN spec) > > This is exactly my view. > (So far, the FN draft does not define any methods in FN, IIRC, but it > certainly can.) This I do not understand, in what way would you say the FN draft defines methods, if not in FN-form? > > I have not heard anyone saying that an FN spec can not > > define its own methods formally. > > Actually, the *only* thing an FN spec can do is define > encoding methods formally. I meant in FN-form, while the opposite is plain English. Anyway, which of these would you call "external", or whatever term we are now using? /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 04:43:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06675 for ; Fri, 1 Oct 2004 04:43:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJ8t-0001ZO-5d for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 04:51:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIm5-0001nZ-08; Fri, 01 Oct 2004 04:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIbD-0007Xq-M8 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 04:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04823 for ; Fri, 1 Oct 2004 04:17:06 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIja-0000zH-Jl for rohc@ietf.org; Fri, 01 Oct 2004 04:25:49 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 09:17:14 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A211C@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , "'Carsten Bormann'" Date: Fri, 1 Oct 2004 09:17:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: rohc@ietf.org Subject: [rohc] RE: FN as humour X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 I'm not sure how much point there is in replying to this, I think we probably need Kristofer's mediation skills again, but I'll give it a go anyway... Inline >> =) I try to mix a bit of humour into my posts as arguing all >> day can put you in a bad frame of mind =) Still the point I >> was trying to make was not a joke. I hope this mix of humour >> and content is not a problem? Please say if it is, and I'll >> try to stop =) > >That is fine, I we are all fine with and appreciate humour, as >well as rather direct and sometimes *hard* discussions. Agreed. And of course the hardest discussions are always over the more trivial issues. Almost always syntax in fact =) > >However, I could not see and can not see anything but humour >in that example. I think the only intended humour was the "being dead for two months" gag. > If a method is missing, there is obviously >an error in the FN-based specification, Yes, that's right, I agree. And the whole point of this is to make errors (which *will* happen) easier to spot and disentangle. >... If it is defined somewhere else, there will >be a reference to that place. Without a reference, it is >actually an undefined method, and it is an error in the spec. I think the issue we're having here is that you are thinking only "finished product", whereas I am thinking about the development process too. A key point here being that whilst the finished profile will be in Internet Draft form, there is a long period where all that is passed around is the FN, and the English text just doesn't get updated. During that period, the FN is all you've got to go on. Due to the way this kind of work gets done, there will be errors in the spec. People's availability comes and goes. Sometimes key people are unavailable for months at a time, in which case you want the notation they've written to be as explicit as possible. However, even *after* the whole thing is finished, it's still useful to the reader to have the underscores in, since it tells them instantly where to look for the definition of the method - in the FN or in the English text. If this is understood then I don't think I've got anything to add. If any of it is not understood then I'm happy to clarify =) _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 05:01:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08055 for ; Fri, 1 Oct 2004 05:01:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJR1-00021s-A4 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 05:10:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJEx-0008Qa-0m; Fri, 01 Oct 2004 04:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJ2P-0005ih-S5 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 04:45:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06755 for ; Fri, 1 Oct 2004 04:45:12 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJAn-0001aN-2B for rohc@ietf.org; Fri, 01 Oct 2004 04:53:56 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 09:45:26 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A211D@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 09:45:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 ]> > What I have thought all the time was that: ]> > ]> > An encoding method is ]> > -- either defined in English (in the FN draft or in the ]> > draft giving the FN spec) ]> > -- or defined in FN, i.e. by giving an FN structure that ]> > defines the encoding method in terms of other encoding ]> > methods, field lists, and let-expressions (in the FN ]> > draft or in the draft giving the FN spec) ]> ]> This is exactly my view. ]> (So far, the FN draft does not define any methods in FN, IIRC, but it ]> certainly can.) ] ]This I do not understand, in what way would you say the FN draft ]defines methods, if not in FN-form? Ah OK, well I think I can answer this question! The FN draft defines methods in English. The only encoding that is defined in the notation itself is list encoding. It is a good point that we *could* define all the encoding methods using the FN itself, but I don't think that would be particularly helpful in some cases, "lsb" encoding in particular would be very difficult to define in the FN and hard to read. But that's why we have methods like that as primitives in the FN! ] ]> > I have not heard anyone saying that an FN spec can not ]> > define its own methods formally. ]> ]> Actually, the *only* thing an FN spec can do is define ]> encoding methods formally. ] ]I meant in FN-form, while the opposite is plain English. It's true nobody has said the FN spec "can not" define its own methods in FN-form, it's just not been done - do we want to do this? It would be useful for verification purposes. ] ]Anyway, which of these would you call "external", or whatever ]term we are now using? OK, I think I can answer this too. There are basically three kinds of encoding methods, 1. those defined as primitives in the FN draft ("irregular", "lsb", "static" etc.), 2. those defined in the FN part of the profile as structures (including list structures), and 3. those referenced in the FN part of the profile, but rigorously defined outside the FN part of the profile. OK, so now I have a question, as I think I may have misunderstood you. Are you saying that there should be no category 3 here? I.e. that if an encoding method isn't be defined in the FN part of a profile, then it must be defined in the FN-draft? (i.e. are you advocating that we return to the pre IETF60 scheme where we had gazillions of encoding methods in the FN draft)? Regards Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailman-bounces@ietf.org Fri Oct 1 06:26:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14640 for ; Fri, 1 Oct 2004 06:26:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDKke-0003kC-Vb for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 06:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJem-0001GX-6Y for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 05:24:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rohc-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:08:51 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rohc-web-archive@ietf.org: List Password // URL ---- -------- rohc@ietf.org umDk https://www1.ietf.org/mailman/options/rohc/rohc-web-archive%40ietf.org From rohc-bounces@ietf.org Fri Oct 1 11:12:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08471 for ; Fri, 1 Oct 2004 11:12:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDPDa-0000nT-4T for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 11:21:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKXG-00026r-O2; Fri, 01 Oct 2004 06:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJcu-00009l-Gp for rohc@megatron.ietf.org; Fri, 01 Oct 2004 05:22:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09340 for ; Fri, 1 Oct 2004 05:22:54 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJlH-0002Rg-Rh for rohc@ietf.org; Fri, 01 Oct 2004 05:31:39 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i919MgYO005670; Fri, 1 Oct 2004 11:22:43 +0200 (MEST) In-Reply-To: <415D005A.6050001@effnet.com> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2115@rsys004a.roke.co.uk> <415D005A.6050001@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <717F5AD8-138B-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 11:22:40 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "Finking, Robert" , rohc@ietf.org, "'Ghyslain Pelletier \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Oct 01 2004, at 08:59 Uhr, Kristofer Sandlund wrote: > Field Width Comments Fine with me. I'd remove the "normally" -- for now, they only can occur after field names in field lists. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:21:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19869 for ; Fri, 1 Oct 2004 12:21:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQIe-0002Lt-CP for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:30:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDODt-0001nq-24; Fri, 01 Oct 2004 10:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKDQ-0007by-PS for rohc@megatron.ietf.org; Fri, 01 Oct 2004 06:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12488 for ; Fri, 1 Oct 2004 06:00:38 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDKLo-0003HG-Dw for rohc@ietf.org; Fri, 01 Oct 2004 06:09:23 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i91A0RHw027069; Fri, 1 Oct 2004 12:00:29 +0200 (MEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <83B79D65-1390-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 11:58:59 +0200 To: "Lars-Erik Jonsson (LU/EAB)" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: "'Finking, Robert'" , rohc@ietf.org, Carsten Bormann , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit >> This is exactly my view. >> (So far, the FN draft does not define any methods in FN, IIRC, but it >> certainly can.) > > This I do not understand, in what way would you say the FN draft > defines methods, if not in FN-form? Most are defined using English language. >>> I have not heard anyone saying that an FN spec can not >>> define its own methods formally. >> >> Actually, the *only* thing an FN spec can do is define >> encoding methods formally. > > I meant in FN-form, while the opposite is plain English. Yes, this is what I mean when I say "formally". "defined formally" and "defined in FN" are synonymous here. > Anyway, which of these would you call "external", or whatever > term we are now using? I would like to get rid of the term "external". It would be nice to have a word for "encoding method defined in english language within the text of a spec using FN", such as inferred methods defined based on properties of the protocol being compressed. This *may* be what some of us called "external", but I'm not even sure about that. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:33:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22009 for ; Fri, 1 Oct 2004 12:33:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQU2-0002bL-KQ for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:42:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPJ2-0005xF-Jp; Fri, 01 Oct 2004 11:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDL4y-0001DA-Bl for rohc@megatron.ietf.org; Fri, 01 Oct 2004 06:56:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17045 for ; Fri, 1 Oct 2004 06:55:57 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLDL-0004I9-L5 for rohc@ietf.org; Fri, 01 Oct 2004 07:04:43 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91AtrfM017839 for ; Fri, 1 Oct 2004 12:55:54 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 12:55:53 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 12:55:47 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Kristofer Sandlund'" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 12:44:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 Oct 2004 10:55:53.0838 (UTC) FILETIME=[38D8A0E0:01C4A7A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Thanks Kristoffer, Well, I agree with your proposal since this is in substance where I am = trying to get at. But I don't agree with how it should look like: > uncompressed_format =3D discriminator [ 8 ], > tcp.seq_number [ 32 ], > tcp.flags.ecn [ 2 ], What I'd want to get at is the following: uncompressed_format =3D discriminator, %[ 8 ] tcp.seq_number, %[ 32 ] tcp.flags.ecn, %[ 2 ] Hence, the annotation is there (for tool-minded people) but it is = formally only a mere comment. Otherwise, it is still embedded into the formalized notation (and the = annotation comes before the ','). AND I will gladly remove any mention of tools in the draft if everyone = agrees. Does this not make more sense? ///Ghyslain -- Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 8 404 29 43 Mobile: +46 (0) 70 264 83 14 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com ----------------------------------- The opinions expressed in this message are my personal opinions. These opinions are not necessarily those of my employer, unless stated otherwise. ----------------------------------- > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 1 oktober 2004 09:00 > To: Finking, Robert > Cc: Ghyslain Pelletier (LU/EAB); rohc@ietf.org; Carsten Bormann > Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - > Wednesd ay's update ) >=20 >=20 > Hi, >=20 > since this discussion seems to deteriorate into religious=20 > warfare, let me=20 > suggest a compromise. If I have managed to misunderstand the=20 > points of conflict=20 > after 100s of mail of the subject, please do hit me over the=20 > head with a mail=20 > swarm and I'll butt out of this issue forever. >=20 > We have all agreed that the annotations don't actually have a=20 > normative meaning=20 > so why not do the following: > - Relax the text around them to clearly show that this is=20 > actually just a=20 > comment and does not mean anything formal. > - Remove all mention of tools. If someone wants to write=20 > parsers or use tools,=20 > then fine, but why mention it in the specification? If a=20 > profile writer happens=20 > to abuse these for some reason, they are still just comments. > - Rename them from Annotations to "Field Width Comments" to=20 > emphasize that these=20 > are COMMENTS >=20 > Can Ghyslain agree on keeping them then? And also, can=20 > Carsten and Robert agree=20 > to this kind of reduction of them? >=20 > My suggestion for a replacement text is the following: >=20 > 4.7 Comments >=20 > Comments do not affect the formal meaning of what is > notated, but can be used to improve readability. Their use is > optional. >=20 > ................ >=20 > >=20 > 4.7.3 Field Width Comments >=20 > A special type of comment that can be used to help the=20 > reader interpret=20 > packet formats is bitfield width comments. As all comments,=20 > these have no formal=20 > meaning, but normally only appears immediately after a field=20 > name. These=20 > comments use a "[" and "]" as delimiters. Enclosed within=20 > these brackets, a=20 > number indicating the width of the preceding field should be written. >=20 > For example: >=20 > uncompressed_format =3D discriminator [ 8 ], > tcp.seq_number [ 32 ], > tcp.flags.ecn [ 2 ], >=20 > anything, and=20 > there is no mention of tools or other "offending" words.=20 > There is no description=20 > of what happens if they are "wrong" etc which also makes it=20 > clear that these do=20 > not have any kind of meaning. The text can be improved if you=20 > accept what I'm=20 > trying to suggest> >=20 > Can they really offend anyone now? If the problem is the use=20 > of brackets, then=20 > the same person should also be offended by the fact that we=20 > can have both "%"=20 > and "/* ... */" comments. And this does in no way stop the=20 > use of parsing tools. >=20 > /Kristofer Sandlund, Effnet AB >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:34:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22153 for ; Fri, 1 Oct 2004 12:34:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQUR-0002bp-U0 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:42:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPJ6-0005zF-SR; Fri, 01 Oct 2004 11:26:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDL5Z-0001HC-Ss for rohc@megatron.ietf.org; Fri, 01 Oct 2004 06:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17077 for ; Fri, 1 Oct 2004 06:56:35 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLDn-0004IW-VS for rohc@ietf.org; Fri, 01 Oct 2004 07:05:21 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91AuMRU013123 for ; Fri, 1 Oct 2004 12:56:22 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 12:56:22 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 12:56:07 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Finking, Robert'" , rohc@ietf.org Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 12:44:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 10:56:22.0571 (UTC) FILETIME=[49F8EFB0:01C4A7A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > Ah, OK, so is the sticking point this: > > That you think it is possible to have tools without the > spec providing > the syntax they need to work on, whereas I (and I assume > Carsten) don't? Yes. This is my opinion. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:34:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22275 for ; Fri, 1 Oct 2004 12:34:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQVI-0002dl-UK for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:43:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPKe-0006rQ-4g; Fri, 01 Oct 2004 11:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDL9K-0001wG-HL for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17374 for ; Fri, 1 Oct 2004 07:00:28 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLHW-0004Ld-J0 for rohc@ietf.org; Fri, 01 Oct 2004 07:09:14 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91B0DWR002739 for ; Fri, 1 Oct 2004 13:00:13 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 13:00:13 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:00:08 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Carsten Bormann'" , "Lars-Erik Jonsson (LU/EAB)" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 12:47:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 11:00:13.0451 (UTC) FILETIME=[D3966DB0:01C4A7A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'Finking, Robert'" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > > Anyway, which of these would you call "external", or whatever > > term we are now using? > > I would like to get rid of the term "external". Good. I obviously am fine with this. > It would be nice to have a word for "encoding method defined > in english > language within the text of a spec using FN", such as > inferred methods > defined based on properties of the protocol being compressed. This > *may* be what some of us called "external", but I'm not even > sure about > that. I don't think that this is what _everyone_ meant by external, since in the draft I've seen the text did imply "a pointer to something". I like the way you express it above, it is more inline with what I'd like to see and I think that the discussion seemed to converged that way. I'll suggest some edits later. > Gruesse, Carsten > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:37:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22438 for ; Fri, 1 Oct 2004 12:37:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQYB-0002iq-0R for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:46:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPMh-0000Jf-Q6; Fri, 01 Oct 2004 11:30:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDLHW-0003ZL-AF for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:08:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18054 for ; Fri, 1 Oct 2004 07:08:55 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLPv-0004VT-G2 for rohc@ietf.org; Fri, 01 Oct 2004 07:17:42 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91B8sWR004609 for ; Fri, 1 Oct 2004 13:08:54 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 13:08:54 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:08:45 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Finking, Robert'" , "'Carsten Bormann'" Date: Fri, 1 Oct 2004 12:53:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 11:08:54.0529 (UTC) FILETIME=[0A2C9F10:01C4A7A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: rohc@ietf.org Subject: [rohc] RE: FN as humour X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > >> =) I try to mix a bit of humour into my posts as arguing all > >> day can put you in a bad frame of mind =) Still the point I > >> was trying to make was not a joke. I hope this mix of humour > >> and content is not a problem? Please say if it is, and I'll > >> try to stop =) > > > >That is fine, I we are all fine with and appreciate humour, as > >well as rather direct and sometimes *hard* discussions. > > Agreed. And of course the hardest discussions are always over the more > trivial issues. Almost always syntax in fact =) True, but often things that might look minor can be rather significant since the actual problem might be in differences in how one envision basic fundamentals. > >However, I could not see and can not see anything but humour > >in that example. > I think the only intended humour was the "being dead for two > months" gag. > > > If a method is missing, there is obviously > >an error in the FN-based specification, > > Yes, that's right, I agree. And the whole point of this is to > make errors (which *will* happen) easier to spot and disentangle. > > >... If it is defined somewhere else, there will > >be a reference to that place. Without a reference, it is > >actually an undefined method, and it is an error in the spec. > > I think the issue we're having here is that you are thinking > only "finished product", whereas I am thinking about the > development process too. Not really, but I rather think there is two completely different views on how the standardisation process works. In a completed new standard, errors are hopefully gone. However, during development I fully agree that there might be missing pieces. What I can not understand is what the underscores will buy you, and I am not totally sure for which methods you will use them either. Is the differentiation between FN-based methods versus English-text methods? If you do not have the underscores, what will happen, please give a precise and realistic example of a method that you would like to use underscore for, and what would be the consequences of not having the underscore. > A key point here being that whilst the finished profile will > be in Internet Draft form, there is a long period where all > that is passed around is the FN, and the English text just > doesn't get updated. During that period, the FN is all > you've got to go on. If this is a key point, I disagree with you even more. When defining a new profile, you will not normally start with the packet formats, rather the other way around. The TCP work we are doing right now is probably the trickiest we should be able to think of, as we are defining the whole notation concept in parallel. > However, even *after* the whole thing is finished, it's > still useful to the reader to have the underscores in, > since it tells them instantly where to look for the > definition of the method - in the FN or in the English > text. I see no actual difference between the two ways of defining a method, the only difference is that FN methods might (will) be machine readable, while the English text ones will not. Thus I do not buy this argument about being useful to a reader. It just creates an artificial differentiation between two kind of methods. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:38:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22516 for ; Fri, 1 Oct 2004 12:38:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQZ2-0002kK-QE for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:47:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPNg-0000sJ-42; Fri, 01 Oct 2004 11:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDLL1-0004Gx-Qy for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:12:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18282 for ; Fri, 1 Oct 2004 07:12:33 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLTF-0004Zq-W4 for rohc@ietf.org; Fri, 01 Oct 2004 07:21:19 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91BCKfM022629 for ; Fri, 1 Oct 2004 13:12:20 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 13:12:19 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:12:19 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Ghyslain Pelletier (LU/EAB)" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 13:03:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 11:12:19.0583 (UTC) FILETIME=[846560F0:01C4A7A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "'Finking, Robert'" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I have a feeling we a converging, if not yet to completely common opinions but at least towards common terminology and understandings. /L-E > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB) > Sent: den 1 oktober 2004 12:48 > To: 'Carsten Bormann'; Lars-Erik Jonsson (LU/EAB) > Cc: 'Finking, Robert'; rohc@ietf.org > Subject: RE: [rohc] RE: External Encoding Methods > > > > > Anyway, which of these would you call "external", or whatever > > > term we are now using? > > > > I would like to get rid of the term "external". > > Good. I obviously am fine with this. > > > It would be nice to have a word for "encoding method defined > > in english > > language within the text of a spec using FN", such as > > inferred methods > > defined based on properties of the protocol being compressed. This > > *may* be what some of us called "external", but I'm not even > > sure about > > that. > > I don't think that this is what _everyone_ meant by external, > since in the draft I've seen the text did imply "a pointer to > something". > > I like the way you express it above, it is more inline with > what I'd like to see and I think that the discussion seemed > to converged that way. I'll suggest some edits later. > > > Gruesse, Carsten > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:39:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22618 for ; Fri, 1 Oct 2004 12:39:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQa1-0002mt-6n for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:48:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPPV-0001rD-TZ; Fri, 01 Oct 2004 11:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDLS7-0005Mu-SC for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:19:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18887 for ; Fri, 1 Oct 2004 07:19:53 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLaX-0004iJ-Ij for rohc@ietf.org; Fri, 01 Oct 2004 07:28:39 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i91AItLh014491 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Oct 2004 12:18:56 +0200 Message-ID: <415D3D76.7040906@effnet.com> Date: Fri, 01 Oct 2004 13:20:22 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by effnet.com id i91AItLh014491 X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "'rohc@ietf.org'" , "Finking, Robert" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable For the, it does not matter if these are written as uncompressed_format =3D discriminator [ 8 ], or uncompressed_format =3D discriminator, [ 8 ] or uncompressed_format =3D discriminator, %[ 8 ] or uncompressed_format =3D discriminator /*[ 8 ]*/, or uncompressed_format =3D discriminator, /*[ 8 ]*/ now that we have agreed on what we actually want them to do. Fight it out= among=20 yourselves, but please agree in less than 100 mails this time ;) BR, Kristofer Ghyslain Pelletier (LU/EAB) wrote: > Thanks Kristoffer, >=20 > Well, I agree with your proposal since this is in substance where I am = trying to get at. >=20 > But I don't agree with how it should look like: >=20 >=20 >> uncompressed_format =3D discriminator [ 8 ], >> tcp.seq_number [ 32 ], >> tcp.flags.ecn [ 2 ], >=20 >=20 > What I'd want to get at is the following: >=20 > uncompressed_format =3D discriminator, %[ 8 ] > tcp.seq_number, %[ 32 ] > tcp.flags.ecn, %[ 2 ] >=20 > Hence, the annotation is there (for tool-minded people) but it is forma= lly only a mere comment. > Otherwise, it is still embedded into the formalized notation (and the a= nnotation comes before the ','). > AND I will gladly remove any mention of tools in the draft if everyone = agrees. >=20 > Does this not make more sense? >=20 > ///Ghyslain >=20 > -- > Ghyslain Pelletier, Dipl. Ing. > Wireless IP Optimizations > Ericsson Research, Corporate Unit >=20 > Ericsson AB, Laboratoriegr=E4nd 11 > Box 920, S-97128 Lule=E5, SWEDEN > Phone : +46 (0) 8 404 29 43 > Mobile: +46 (0) 70 264 83 14 > Ghyslain.Pelletier@ericsson.com > http://www.ericsson.com >=20 > ----------------------------------- > The opinions expressed in this > message are my personal opinions. > These opinions are not > necessarily those of my employer, > unless stated otherwise. > ----------------------------------- >=20 >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] >>Sent: den 1 oktober 2004 09:00 >>To: Finking, Robert >>Cc: Ghyslain Pelletier (LU/EAB); rohc@ietf.org; Carsten Bormann >>Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - >>Wednesd ay's update ) >> >> >>Hi, >> >>since this discussion seems to deteriorate into religious=20 >>warfare, let me=20 >>suggest a compromise. If I have managed to misunderstand the=20 >>points of conflict=20 >>after 100s of mail of the subject, please do hit me over the=20 >>head with a mail=20 >>swarm and I'll butt out of this issue forever. >> >>We have all agreed that the annotations don't actually have a=20 >>normative meaning=20 >>so why not do the following: >>- Relax the text around them to clearly show that this is=20 >>actually just a=20 >>comment and does not mean anything formal. >>- Remove all mention of tools. If someone wants to write=20 >>parsers or use tools,=20 >>then fine, but why mention it in the specification? If a=20 >>profile writer happens=20 >>to abuse these for some reason, they are still just comments. >>- Rename them from Annotations to "Field Width Comments" to=20 >>emphasize that these=20 >>are COMMENTS >> >>Can Ghyslain agree on keeping them then? And also, can=20 >>Carsten and Robert agree=20 >>to this kind of reduction of them? >> >>My suggestion for a replacement text is the following: >> >>4.7 Comments >> >> Comments do not affect the formal meaning of what is >> notated, but can be used to improve readability. Their use is >> optional. >> >> ................ >> >> >> >>4.7.3 Field Width Comments >> >> A special type of comment that can be used to help the=20 >>reader interpret=20 >>packet formats is bitfield width comments. As all comments,=20 >>these have no formal=20 >>meaning, but normally only appears immediately after a field=20 >>name. These=20 >>comments use a "[" and "]" as delimiters. Enclosed within=20 >>these brackets, a=20 >>number indicating the width of the preceding field should be written. >> >> For example: >> >> uncompressed_format =3D discriminator [ 8 ], >> tcp.seq_number [ 32 ], >> tcp.flags.ecn [ 2 ], >> >>>anything, and=20 >>there is no mention of tools or other "offending" words.=20 >>There is no description=20 >>of what happens if they are "wrong" etc which also makes it=20 >>clear that these do=20 >>not have any kind of meaning. The text can be improved if you=20 >>accept what I'm=20 >>trying to suggest> >> >>Can they really offend anyone now? If the problem is the use=20 >>of brackets, then=20 >>the same person should also be offended by the fact that we=20 >>can have both "%"=20 >>and "/* ... */" comments. And this does in no way stop the=20 >>use of parsing tools. >> >>/Kristofer Sandlund, Effnet AB >> _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:40:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22688 for ; Fri, 1 Oct 2004 12:40:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQap-0002oZ-Kr for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:49:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPUQ-0003xm-Vj; Fri, 01 Oct 2004 11:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDLga-0007vi-3Q for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:34:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19880 for ; Fri, 1 Oct 2004 07:34:49 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLor-0004yW-NB for rohc@ietf.org; Fri, 01 Oct 2004 07:43:36 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i91BYRHj020150; Fri, 1 Oct 2004 13:34:28 +0200 (MEST) In-Reply-To: <415D3D76.7040906@effnet.com> References: <415D3D76.7040906@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97FA132A-139D-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 13:32:36 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Oct 01 2004, at 13:20 Uhr, Kristofer Sandlund wrote: > For the, it does not matter if these are written as > > uncompressed_format = discriminator [ 8 ], fine > or > uncompressed_format = discriminator, [ 8 ] this "field width comment" is not directly after a field name in a field list -- not fine > or > uncompressed_format = discriminator, %[ 8 ] fine (but won't be checked by tool) > or > uncompressed_format = discriminator /*[ 8 ]*/, ditto > or > uncompressed_format = discriminator, /*[ 8 ]*/ ditto. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:40:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22754 for ; Fri, 1 Oct 2004 12:40:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQb5-0002pT-HO for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:49:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPVP-0004Wk-CK; Fri, 01 Oct 2004 11:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDLkg-00007T-2o for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:39:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20180 for ; Fri, 1 Oct 2004 07:39:03 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLt6-00053G-J6 for rohc@ietf.org; Fri, 01 Oct 2004 07:47:50 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91Bd3WR010461 for ; Fri, 1 Oct 2004 13:39:03 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 13:39:03 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:39:03 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Kristofer Sandlund'" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 13:29:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 11:39:03.0183 (UTC) FILETIME=[403751F0:01C4A7AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Carsten Bormann , "'rohc@ietf.org'" , "Finking, Robert" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > now that we have agreed on what we actually want them to do. > Fight it out among > yourselves, but please agree in less than 100 mails this time ;) > What I'd like to make sure that we have agreed, is that annotations are not to be formal - meaning that they cannot either be extended in the future to specify e.g. attributes to be used my coding methods etc such as it was suggested before (expanding annotations is currently explicitly allowed in the text Robert sent us this week). Do we all agree on this view? Maybe I was not clear before, but I don't care much about that they are included (although the printer in me does prefer the % x bits comment) in the spec, as long as they have no formal meaning and that it does not open up a mechanism for specifying other things (and mainly things targeted towards verification tools). So, in this respect, in the ROHC-FN draft - the only thing that we need to define are comments using % or /**/. In the ROHC-TCP spec we can have a comment just before the FN spec of the packet formats that explain what the % [ x] means and its purpose, nothing more. Is it possible to agree on this? /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:41:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22802 for ; Fri, 1 Oct 2004 12:41:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQbV-0002q6-W3 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:50:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPVT-0004Yj-US; Fri, 01 Oct 2004 11:39:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDLl3-0000H4-Sg for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:39:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20209 for ; Fri, 1 Oct 2004 07:39:27 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLtK-00053T-A4 for rohc@ietf.org; Fri, 01 Oct 2004 07:48:13 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91BdGWR010689 for ; Fri, 1 Oct 2004 13:39:16 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 13:39:15 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:39:15 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "Lars-Erik Jonsson (LU/EAB)" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 13:32:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 Oct 2004 11:39:15.0844 (UTC) FILETIME=[47C33C40:01C4A7AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: "'Finking, Robert'" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable All, I have added a suggestion for the text in the FN draft to replace the = section on "External Encoding Methods" in the issue tracker. Have a = look and let me know if what I wrote means anything to you. Suggested text for 4.8.7 ------------------------ 4.8.7. Profile-specific Encoding Methods The library of encoding methods provides a basic and generic set of coding methods. Some additional encodings=20 specific to a particular protocol may however be needed,=20 such as for methods that infer the value of a field from=20 other values. These methods are defined based on the=20 properties of the protocol being compressed. Profiles may define additional encoding methods; the=20 scope of these methods is then local to the profile=20 definition itself, and they can be used as part of the=20 formal definition of the profile as any other methods=20 from the library (see section xxxx). Profile-specific encoding methods must be rigorously defined using either the ROHC-FN syntax or in plain text, as long as its definition provides enough information to unambiguously implement the encoding method in the compressor and the decompressor. These methods should be no less complete than the methods provided herein. ///Ghyslain -- Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 8 404 29 43 Mobile: +46 (0) 70 264 83 14 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com ----------------------------------- The opinions expressed in this message are my personal opinions. These opinions are not necessarily those of my employer, unless stated otherwise. ----------------------------------- > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > Sent: den 1 oktober 2004 13:03 > To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann' > Cc: 'Finking, Robert'; 'rohc@ietf.org' > Subject: RE: [rohc] RE: External Encoding Methods >=20 >=20 > I have a feeling we a converging, if not yet to completely > common opinions but at least towards common terminology and > understandings.=20 >=20 > /L-E >=20 > > -----Original Message----- > > From: Ghyslain Pelletier (LU/EAB)=20 > > Sent: den 1 oktober 2004 12:48 > > To: 'Carsten Bormann'; Lars-Erik Jonsson (LU/EAB) > > Cc: 'Finking, Robert'; rohc@ietf.org > > Subject: RE: [rohc] RE: External Encoding Methods > >=20 > >=20 > > > > Anyway, which of these would you call "external", or whatever > > > > term we are now using? > > >=20 > > > I would like to get rid of the term "external". > >=20 > > Good. I obviously am fine with this. > > =20 > > > It would be nice to have a word for "encoding method defined=20 > > > in english=20 > > > language within the text of a spec using FN", such as=20 > > > inferred methods=20 > > > defined based on properties of the protocol being=20 > compressed. This=20 > > > *may* be what some of us called "external", but I'm not even=20 > > > sure about=20 > > > that. > >=20 > > I don't think that this is what _everyone_ meant by external,=20 > > since in the draft I've seen the text did imply "a pointer to=20 > > something". > >=20 > > I like the way you express it above, it is more inline with=20 > > what I'd like to see and I think that the discussion seemed=20 > > to converged that way. I'll suggest some edits later. > > =20 > > > Gruesse, Carsten > > >=20 > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:41:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22881 for ; Fri, 1 Oct 2004 12:41:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQby-0002rG-L5 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:50:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPVV-0004Zi-AX; Fri, 01 Oct 2004 11:39:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDLlL-0000LI-NG for rohc@megatron.ietf.org; Fri, 01 Oct 2004 07:39:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20231 for ; Fri, 1 Oct 2004 07:39:45 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLtc-00054t-61 for rohc@ietf.org; Fri, 01 Oct 2004 07:48:31 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91BdZRU025962 for ; Fri, 1 Oct 2004 13:39:35 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 13:39:34 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:39:34 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Carsten Bormann'" , Kristofer Sandlund Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 13:37:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 11:39:34.0968 (UTC) FILETIME=[53295380:01C4A7AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: "Finking, Robert" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > > uncompressed_format = discriminator, %[ 8 ] > > fine (but won't be checked by tool) Why can't it be checked by a tool? Doesn't the [ 8 ] only apply to the right-hand side of the statement? /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:44:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23143 for ; Fri, 1 Oct 2004 12:44:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQfC-0002xr-Vy for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:53:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPcN-0007we-Lz; Fri, 01 Oct 2004 11:46:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDM6R-0005fy-HZ for rohc@megatron.ietf.org; Fri, 01 Oct 2004 08:01:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21709 for ; Fri, 1 Oct 2004 08:01:32 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMEt-0005a4-7M for rohc@ietf.org; Fri, 01 Oct 2004 08:10:19 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:01:43 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2122@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Ghyslain Pelletier (LU/EAB)'" , "Lars-Erik Jonsson (LU/EAB)" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 13:01:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable ]I have added a suggestion for the text in the FN draft to replace the ]section on "External Encoding Methods" in the issue tracker. Have a=20 ]ook and let me know if what I wrote means anything to you. ] ]Suggested text for 4.8.7 ]------------------------ ] ]4.8.7. Profile-specific Encoding Methods ] ] The library of encoding methods provides a basic and ] generic set of coding methods. Some additional encodings=20 ] specific to a particular protocol may however be needed,=20 ] such as for methods that infer the value of a field from=20 ] other values. These methods are defined based on the=20 ] properties of the protocol being compressed. ] ] Profiles may define additional encoding methods; the=20 ] scope of these methods is then local to the profile=20 ] definition itself, and they can be used as part of the=20 ] formal definition of the profile as any other methods=20 ] from the library (see section xxxx). ] ] Profile-specific encoding methods must be rigorously ] defined using either the ROHC-FN syntax or in plain ] text, as long as its definition provides enough ] information to unambiguously implement the encoding ] method in the compressor and the decompressor. These ] methods should be no less complete than the methods ] provided herein. This is good Ghyslain, I like this text a lot. I agree to this change, though I would like to leave open the question of whether we need = another paragraph (something along the lines of): Profile-specific encoding methods must have identifier which start with = an underscore in order to make them visually distinct from other encoding methods. Regards Raffles ///Ghyslain -- Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 8 404 29 43 Mobile: +46 (0) 70 264 83 14 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com ----------------------------------- The opinions expressed in this message are my personal opinions. These opinions are not necessarily those of my employer, unless stated otherwise. ----------------------------------- > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > Sent: den 1 oktober 2004 13:03 > To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann' > Cc: 'Finking, Robert'; 'rohc@ietf.org' > Subject: RE: [rohc] RE: External Encoding Methods >=20 >=20 > I have a feeling we a converging, if not yet to completely > common opinions but at least towards common terminology and > understandings.=20 >=20 > /L-E >=20 > > -----Original Message----- > > From: Ghyslain Pelletier (LU/EAB)=20 > > Sent: den 1 oktober 2004 12:48 > > To: 'Carsten Bormann'; Lars-Erik Jonsson (LU/EAB) > > Cc: 'Finking, Robert'; rohc@ietf.org > > Subject: RE: [rohc] RE: External Encoding Methods > >=20 > >=20 > > > > Anyway, which of these would you call "external", or whatever > > > > term we are now using? > > >=20 > > > I would like to get rid of the term "external". > >=20 > > Good. I obviously am fine with this. > > =20 > > > It would be nice to have a word for "encoding method defined=20 > > > in english=20 > > > language within the text of a spec using FN", such as=20 > > > inferred methods=20 > > > defined based on properties of the protocol being=20 > compressed. This=20 > > > *may* be what some of us called "external", but I'm not even=20 > > > sure about=20 > > > that. > >=20 > > I don't think that this is what _everyone_ meant by external,=20 > > since in the draft I've seen the text did imply "a pointer to=20 > > something". > >=20 > > I like the way you express it above, it is more inline with=20 > > what I'd like to see and I think that the discussion seemed=20 > > to converged that way. I'll suggest some edits later. > > =20 > > > Gruesse, Carsten > > >=20 > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:46:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23286 for ; Fri, 1 Oct 2004 12:46:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQgR-00031r-5E for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:55:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPfi-000186-AV; Fri, 01 Oct 2004 11:50:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDMJO-0007jf-LH for rohc@megatron.ietf.org; Fri, 01 Oct 2004 08:14:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22758 for ; Fri, 1 Oct 2004 08:14:55 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMRp-0005ob-DL for rohc@ietf.org; Fri, 01 Oct 2004 08:23:43 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91CEtfM011199 for ; Fri, 1 Oct 2004 14:14:55 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 14:14:54 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 14:14:54 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Finking, Robert'" , "Lars-Erik Jonsson (LU/EAB)" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 14:14:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 12:14:54.0930 (UTC) FILETIME=[42C1DB20:01C4A7B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > Profile-specific encoding methods must have identifier which > start with an > > underscore in order to make them visually distinct from other encoding > > methods. Please motivate this? Right now I cannot see the difference between a method being defined within the profile itself or fom the library of encoding method. /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:50:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23599 for ; Fri, 1 Oct 2004 12:50:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQkS-00039M-OP for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 12:59:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPgy-0001d2-Bd; Fri, 01 Oct 2004 11:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDMO9-0000CU-Sf for rohc@megatron.ietf.org; Fri, 01 Oct 2004 08:19:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23130 for ; Fri, 1 Oct 2004 08:19:50 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMWa-0005um-Py for rohc@ietf.org; Fri, 01 Oct 2004 08:28:38 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 13:20:08 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2123@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Ghyslain Pelletier (LU/EAB)'" , "'Kristofer Sandlund'" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 13:19:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Carsten Bormann , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca ]> now that we have agreed on what we actually want them to do. ]> Fight it out among ]> yourselves, but please agree in less than 100 mails this time ;) ]> ] ]What I'd like to make sure that we have agreed, is that annotations ]are not to be formal - meaning that they cannot either be extended in ]the future to specify e.g. attributes to be used my coding methods etc ]such as it was suggested before (expanding annotations is currently ]explicitly allowed in the text Robert sent us this week). Do we all ]agree on this view? OK, I'll agree to that =) ] ]Maybe I was not clear before, but I don't care much about that they are ]included (although the printer in me does prefer the % x bits comment) ]in the spec,... Phew! Well that's the main hurdle then! ]...as long as they have no formal meaning and that it does ]not open up a mechanism for specifying other things (and mainly things ]targeted towards verification tools). I certainly agree it has no formal meaning - and as to what it specifies, my understanding is that it's just plain number of bits and nothing more - is that what you mean? ] ]So, in this respect, in the ROHC-FN draft - the only thing that we need ]to define are comments using % or /**/. In the ROHC-TCP spec we can ]have a comment just before the FN spec of the packet formats that ]explain what the % [ x] means and its purpose, nothing more. ] ]Is it possible to agree on this? Ag, no this is a sticking point. If that was OK, then we wouldn't be having this discussion. The whole point of this syntax is that it enables a tool to do something different from what it does with the other two kinds of comments. We need the tool to be able to differentiate between the comments it should always ignore and those it can interpret. Ordinary comments are completely ignored, you just throw them away before you even start. They are invisible if you like. So, for you suggestion to be OK, it would mean a tool would have to start parsing all the comments along with the rest of the formal notation, which is a complete nightmare. The whole point of the [ ] syntax is that we need something special that's *different* to ordinary comments, so that the tool doesn't throw the content away before it starts, but can easily pick it out and process it. Is the issue here that you don't want a third kind of comment (which is all it will be from a human reader's point of view)? Or is it something else? I feel I'm not quite understanding your objection! Please explain =) Thanks in advance Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:51:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23730 for ; Fri, 1 Oct 2004 12:51:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQlH-0003Bg-C0 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPjM-0002jP-Az; Fri, 01 Oct 2004 11:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDMaE-0001ur-AZ for rohc@megatron.ietf.org; Fri, 01 Oct 2004 08:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24031 for ; Fri, 1 Oct 2004 08:32:19 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMif-00067q-7n for rohc@ietf.org; Fri, 01 Oct 2004 08:41:06 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i91BVDLh014676 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Oct 2004 13:31:14 +0200 Message-ID: <415D4E68.3080308@effnet.com> Date: Fri, 01 Oct 2004 14:32:40 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2123@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2123@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" , "'Ghyslain Pelletier \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Comments below. > ] > ]So, in this respect, in the ROHC-FN draft - the only thing that we need > ]to define are comments using % or /**/. In the ROHC-TCP spec we can > ]have a comment just before the FN spec of the packet formats that > ]explain what the % [ x] means and its purpose, nothing more. > ] > ]Is it possible to agree on this? > > Ag, no this is a sticking point. If that was OK, then we wouldn't be having this discussion. The whole point of this syntax is that it enables a tool to do something different from what it does with the other two kinds of comments. > > We need the tool to be able to differentiate between the comments it should always ignore and those it can interpret. Ordinary comments are completely ignored, you just throw them away before you even start. They are invisible if you like. > > So, for you suggestion to be OK, it would mean a tool would have to start parsing all the comments along with the rest of the formal notation, which is a complete nightmare. The whole point of the [ ] syntax is that we need something special that's *different* to ordinary comments, so that the tool doesn't throw the content away before it starts, but can easily pick it out and process it. > > Is the issue here that you don't want a third kind of comment (which is all it will be from a human reader's point of view)? Or is it something else? I feel I'm not quite understanding your objection! Please explain =) > I agree with Robert here, in that I don't see why Ghyslain is so vehemently against the "["-style comments. Like I said earlier, if you object to those, then you should also object to "/*" comments for crying out loud. If there are two or three different deliminators for comments should not make any difference to you or to anyone else. As for the other camp, I can't see why on earth you would object to the /*[2]*/ way of writing them. If you cannot write a parser that looks for "/*[" instead of "[", then the problem does not really lie in the notation ;) (yes, this would make "non-bitfield" comments unable to start with "[" but when would this happen? And If you think this is an issue, let's ban it then). So once again, I think both camps are fighting over something that is not an issue. Someone please yield so we can move on to things that actually are issues. /Kristofer (trying to mediate as Bad Cop when Good Cop did not work) > Thanks in advance > > Raffles > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 12:51:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23798 for ; Fri, 1 Oct 2004 12:51:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQlc-0003DU-Dh for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:00:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPkP-0003Fc-Ly; Fri, 01 Oct 2004 11:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDMiw-0002fx-K5 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 08:41:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24776 for ; Fri, 1 Oct 2004 08:41:19 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMrL-0006JF-IZ for rohc@ietf.org; Fri, 01 Oct 2004 08:50:07 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91CfHWR026265 for ; Fri, 1 Oct 2004 14:41:17 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 14:41:17 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 14:41:17 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Finking, Robert'" , "'Kristofer Sandlund'" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 14:41:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 Oct 2004 12:41:17.0356 (UTC) FILETIME=[F1F4E6C0:01C4A7B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable > Is the issue here that you don't want a third kind of comment=20 > (which is all it will be from a human reader's point of=20 > view)? Or is it something else? I feel I'm not quite=20 > understanding your objection! Please explain =3D) Again - I don't believe that there should be things included in a = specification for the purpose of verification tools that in turn are = not even specified themselves (not that I want to do that either ; ), = and if we start adding such things why not start adding other stuff for = other type of verifications then? But hey, I'm sick of this discussion (surely just like everyone else), = you and Carsten can have it the way you want - so I ain't saying = anything else on that stupid topic. I'll just bend and shut up = [everyone - cheer now!]. Then I'll just restrict the text of the annotation to make it a = parseable comment (thus I give up that these should not be formal) that = has the fixed meaning as to meaning the number of bits of the field BUT = will include text to restrict their use to that sole purpose, i.e. = can't/won't be extended. And for the record, I perfectly understand why you think this needs to = be in, how it works and how you want to use it, but it is still of my = opinion that this is not appropriate in a spec since it is very much = dependant on what Carsten wants to do with his parser and how he want = to make verifications - IT HAS NOTHING TO DO WITH SPECIFYING PACKET = FORMATS (sanity checks don't specify anything, only redundancy, and = then you need to keep text in the FN to state what happens if these = disagree and so on - bleuh). /Ghyslain PS: The reason why I am _very_ annoyed by all this is that I spent a = whole week of my summer vacations to try to make the final touch to the = FN spec and make it for the IETF 60th deadline (and we've done most of = these updates together) following the week in Lule=E5 during the TCP/FN = WS, and all those present we agreeing that -03 was very very close to = the way we wanted this to be. At IETF, someone just started throwing = everything out and now we are far from done it seems. We had decided to = drop the Prolog verification. It feels like we could have nailed the = whole thing in time by then in a satisfactory manner but hey... why = stop the fun so early [everyone - boo now...]. And I thought we had agreed on the deadline which is already almost = pass=E9! Call me a printer experiencing a paper jam if you want, that does not = even bother me anymore. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 13:04:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24862 for ; Fri, 1 Oct 2004 13:04:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQyD-0003cG-Vi for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:13:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ0k-0001N1-8U; Fri, 01 Oct 2004 12:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDNbv-0004Nb-S7 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 09:38:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28913 for ; Fri, 1 Oct 2004 09:38:09 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNkK-0007Q9-Hw for rohc@ietf.org; Fri, 01 Oct 2004 09:46:55 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 14:38:23 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2125@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Ghyslain Pelletier (LU/EAB)'" , "Lars-Erik Jonsson (LU/EAB)" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 14:38:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ]> ]> Profile-specific encoding methods must have identifier which ]> start with an ]> ]> underscore in order to make them visually distinct from other encoding ]> ]> methods. ] ] ]Please motivate this? ] ]Right now I cannot see the difference between a method being defined ]ithin the profile itself or fom the library of encoding method. Well, I thought we'd been motivating it all along, but here goes again. To give a specific example (since L-E asked for one earlier), suppose that during development, in the TCP profile you have an encoding method called "satic". I come along and read the FN bit of the profile (please be aware that the English part of the profile and the FN for the packet formats are updated independently), and have no clue as to whether this is supposed to be "static" or is supposed to be an encoding method defined in the English text. Hence I can't correct it. This wouldn't be a problem except that most of the time the majority of the people concerned with ROHC-FN aren't available, so that you feel somewhat like you're working in a vacuum. Second example. The draft is finished and has made it to RFC stage, as has the TCP profile. Mr E. N. Gineer from Sagem is tasked with developing the compressor/decompressor for Sagem's new phone. He's reading the FN part of the spec and wants to know where to find the definition of the "satic" encoding method. He's pretty sure it's not a primitive encoding method because there are only a few of them and it doesn't ring any bells, so does he need to manually skim through the FN to find the formal definition, or does he need to look up the English text for the reference? He can't tell! However, if an underscore prefix was used... I hope this illustrates the rationale behind this idea. Regards Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 13:04:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24924 for ; Fri, 1 Oct 2004 13:04:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQyH-0003cV-U0 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:13:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ16-0001ej-AU; Fri, 01 Oct 2004 12:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDNcS-0004aq-Om for rohc@megatron.ietf.org; Fri, 01 Oct 2004 09:38:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28959 for ; Fri, 1 Oct 2004 09:38:43 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNkk-0007RB-Af for rohc@ietf.org; Fri, 01 Oct 2004 09:47:29 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91DcVRU027114 for ; Fri, 1 Oct 2004 15:38:31 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 15:38:31 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 15:38:31 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Finking, Robert'" , "Ghyslain Pelletier (LU/EAB)" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 15:38:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 13:38:31.0557 (UTC) FILETIME=[F0E66350:01C4A7BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > This is good Ghyslain, I like this text a lot. I agree to > this change, though I would like to leave open the question > of whether we need another paragraph (something along the > lines of): > > Profile-specific encoding methods must have identifier which > start with an underscore in order to make them visually > distinct from other encoding methods. As you might have expected, I do not want to add this requirement. Actually, I would argue that the FN can not mandate profile definitions to use such an identifier, as that is totally up to the profile writer to decide. If the FN makes such a statement, a profile definition can easily override it, but a profile can also use its own way to separate different kinds of methods. So, making such a requirement/statement in the FN is just moot! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 13:07:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25584 for ; Fri, 1 Oct 2004 13:07:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR1D-0003pu-TD for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:16:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ2U-0002e0-S9; Fri, 01 Oct 2004 12:13:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDNiA-00060V-A7 for rohc@megatron.ietf.org; Fri, 01 Oct 2004 09:44:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29429 for ; Fri, 1 Oct 2004 09:44:36 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNqb-0007YB-PP for rohc@ietf.org; Fri, 01 Oct 2004 09:53:23 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91DiZRU029065 for ; Fri, 1 Oct 2004 15:44:35 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 15:44:35 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 15:44:35 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Kristofer Sandlund'" , "Finking, Robert" Date: Fri, 1 Oct 2004 15:44:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 Oct 2004 13:44:35.0204 (UTC) FILETIME=[C9A68440:01C4A7BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "'rohc@ietf.org'" Subject: [rohc] Annotations, underscores and the remaining TCP/FN stuff X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable ROHCers, Ok, I give up [more cheers!] : ) Let me summarize what comes out of the mess I seem to have created on = the list since yesterday: 1) We'll leave the underscore, we can leave the annotations in. In addition, I will make the following changes to the FN: 2) modify section 4.8.7 as follow: 4.8.7. Profile-specific Encoding Methods The library of encoding methods provides a basic and generic set of coding methods. Some additional encodings=20 specific to a particular protocol may however be needed,=20 such as for methods that infer the value of a field from=20 other values. These methods are defined based on the=20 properties of the protocol being compressed. Profiles may define additional encoding methods; the=20 scope of these methods is then local to the profile=20 definition itself, and they can be used as part of the=20 formal definition of the profile as any other methods=20 from the library (see section xxxx). Profile-specific encoding methods must be rigorously defined using either the ROHC-FN syntax or in plain text, as long as its definition provides enough information to unambiguously implement the encoding method in the compressor and the decompressor. These methods should be no less complete than the methods provided herein. [will add the underscore notation text here] 3) Annotations will be clarified as to: - cannot be extended to mean else than number of bits for field=20 - if in conflict with other part of the specs, they are not to prevail over the spec - will look like this: > uncompressed_format =3D discriminator [ 8 ], =20 4) CRC encoding method a la -03 will be reinstated and will now have the following signature: field ::=3D crc (num_bits, bit_pattern, initial_value,=20 block_data_value, block_data_length) 5) Since I have the token, I will make a round of edits to clean up the document so that I make sure it looks like a specification. In the meantime, we need to find a way to fix the packet formats, have = Carsten (in)validate them and then move on to wglc. Everyone savvy and in agreement with the above? Great - at least this will have almost been useful. Have a great weekend, ///Ghyslain PS: The first ROHC wg draft describing a ROHC-TCP profile came out on = November 17, 2000. -- Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 8 404 29 43 Mobile: +46 (0) 70 264 83 14 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com ----------------------------------- The opinions expressed in this message are my personal opinions. These opinions are not necessarily those of my employer, unless stated otherwise. ----------------------------------- > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 1 oktober 2004 14:33 > To: Finking, Robert > Cc: Ghyslain Pelletier (LU/EAB); 'rohc@ietf.org'; Carsten Bormann > Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - > Wednesd ay's update ) >=20 >=20 > Comments below. >=20 > > ] > > ]So, in this respect, in the ROHC-FN draft - the only thing=20 > that we need=20 > > ]to define are comments using % or /**/. In the ROHC-TCP=20 > spec we can=20 > > ]have a comment just before the FN spec of the packet formats that=20 > > ]explain what the % [ x] means and its purpose, nothing more. > > ] > > ]Is it possible to agree on this? > >=20 > > Ag, no this is a sticking point. If that was OK, then we=20 > wouldn't be having this discussion. The whole point of this=20 > syntax is that it enables a tool to do something different > from what it does with the other two kinds of comments. > >=20 > > We need the tool to be able to differentiate between the=20 > comments it should always ignore and those it can interpret.=20 > Ordinary comments are completely ignored, you just throw them=20 > away before you even start. They are invisible if you like. > >=20 > > So, for you suggestion to be OK, it would mean a tool would=20 > have to start parsing all the comments along with the rest of=20 > the formal notation, which is a complete nightmare. The whole=20 > point of the [ ] syntax is that we need something special=20 > that's *different* to ordinary comments, so that the tool=20 > doesn't throw the content away before it starts, but can=20 > easily pick it out and process it. > >=20 > > Is the issue here that you don't want a third kind of=20 > comment (which is all it will be from a human reader's point=20 > of view)? Or is it something else? I feel I'm not quite=20 > understanding your objection! Please explain =3D) > >=20 >=20 > I agree with Robert here, in that I don't see why Ghyslain is=20 > so vehemently=20 > against the "["-style comments. Like I said earlier, if you=20 > object to those,=20 > then you should also object to "/*" comments for crying out=20 > loud. If there are=20 > two or three different deliminators for comments should not=20 > make any difference=20 > to you or to anyone else. >=20 > As for the other camp, I can't see why on earth you would=20 > object to the /*[2]*/=20 > way of writing them. If you cannot write a parser that looks=20 > for "/*[" instead=20 > of "[", then the problem does not really lie in the notation ;) > (yes, this would make "non-bitfield" comments unable to start=20 > with "[" but when=20 > would this happen? And If you think this is an issue, let's=20 > ban it then). >=20 > So once again, I think both camps are fighting over something=20 > that is not an=20 > issue. Someone please yield so we can move on to things that=20 > actually are issues. >=20 >=20 > /Kristofer (trying to mediate as Bad Cop when Good Cop did not work) >=20 > > Thanks in advance > >=20 > > Raffles > >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 13:08:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25716 for ; Fri, 1 Oct 2004 13:08:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR1c-0003sA-K7 for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ3h-0003SR-NO; Fri, 01 Oct 2004 12:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDNly-0007Rc-Hf for rohc@megatron.ietf.org; Fri, 01 Oct 2004 09:48:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29919 for ; Fri, 1 Oct 2004 09:48:33 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNuH-0007dr-3O for rohc@ietf.org; Fri, 01 Oct 2004 09:57:19 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91DmMRU030084 for ; Fri, 1 Oct 2004 15:48:22 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 15:48:22 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 15:48:22 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Finking, Robert'" , "Ghyslain Pelletier (LU/EAB)" , "'Carsten Bormann'" Subject: RE: [rohc] RE: External Encoding Methods Date: Fri, 1 Oct 2004 15:48:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 13:48:22.0578 (UTC) FILETIME=[512D0920:01C4A7BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab > Well, I thought we'd been motivating it all along, but here > goes again. To give a specific example (since L-E asked for > one earlier), suppose that during development, in the TCP > profile you have an encoding method called "satic". I come > along and read the FN bit of the profile (please be aware > that the English part of the profile and the FN for the > packet formats are updated independently), and have no clue > as to whether this is supposed to be "static" or is supposed > to be an encoding method defined in the English text. We are talkning about ONE specification, I can not understand why you say that text vs FN-part are updated separately, I would rather claim that the natural thing is to make this in parallell. > This wouldn't be a problem except that most > of the time the majority of the people concerned with ROHC-FN > aren't available, so that you feel somewhat like you're > working in a vacuum. This is an IETF WG, involved people is usually just an e-mail message away. And what is in WG documents is developed openly on the mail list. > Second example. The draft is finished and has made it to RFC > stage, as has the TCP profile. Mr E. N. Gineer from Sagem is > tasked with developing the compressor/decompressor for > Sagem's new phone. He's reading the FN part of the spec and > wants to know where to find the definition of the "satic" > encoding method. He's pretty sure it's not a primitive > encoding method because there are only a few of them and it > doesn't ring any bells, so does he need to manually skim > through the FN to find the formal definition, or does he need > to look up the English text for the reference? He can't > tell! However, if an underscore prefix was used... Why is he reading just a minor part of the spec? The spec consists of several parts, but of course you can not expect to understand everything by reading just one part in the middle. > I hope this illustrates the rationale behind this idea. It just makes me more convinced that this artificial separation is completely wrong. I know you have had a hard time with the FN and ROHC-TCP work, which has been a mess during the whole process. However, no underscore in the world had helped us with this. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 13:08:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25850 for ; Fri, 1 Oct 2004 13:08:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR2F-0003v0-Pq for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:17:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ7D-00060Z-4r; Fri, 01 Oct 2004 12:18:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDNzY-0003bz-Qc for rohc@megatron.ietf.org; Fri, 01 Oct 2004 10:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01228 for ; Fri, 1 Oct 2004 10:02:35 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDO80-0007v9-PS for rohc@ietf.org; Fri, 01 Oct 2004 10:11:22 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 15:02:45 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2126@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Ghyslain Pelletier (LU/EAB)'" , "'Kristofer Sandlund'" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Fri, 1 Oct 2004 15:02:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Hi superstars, Comments in line =3D) ] ]But hey, I'm sick of this discussion (surely just like everyone else), = you and Carsten=20 ]can have it the way you want - so I ain't saying anything else on that stupid topic.=20 ]I'll just bend and shut up [everyone - cheer now!]. =3DO no wait, don't capitulate! We don't want you to resign yourself to = this. We want you to realise that our way is best =3D) Just kidding - = thanks for being happy to resolve this! ] ]Then I'll just restrict the text of the annotation to make it a = parseable comment (thus=20 ]I give up that these should not be formal) that has the fixed meaning = as to meaning the=20 ]number of bits of the field BUT will include text to restrict their = use to that sole=20 ]purpose, i.e. can't/won't be extended. Sounds good to me =3D) ] ]And for the record, I perfectly understand why you think this needs to = be in, how it=20 ]works and how you want to use it, but it is still of my opinion that = this is not=20 ]appropriate in a spec since it is very much dependant on what Carsten = wants to do with=20 ]his parser and how he want to make verifications - IT HAS NOTHING TO = DO WITH SPECIFYING=20 ]PACKET FORMATS (sanity checks don't specify anything, only redundancy, = and then you need=20 ]to keep text in the FN to state what happens if these disagree and so = on - bleuh). ] OK, point taken - thanks =3D) ]PS: The reason why I am _very_ annoyed by all this is that I spent a = whole week of my=20 ]summer vacations to try to make the final touch to the FN spec and = make it for the IETF=20 ]60th deadline (and we've done most of these updates together) = following the week in Lule=E5=20 ]during the TCP/FN WS, and all those present we agreeing that -03 was = very very close to=20 ]the way we wanted this to be. At IETF, someone just started throwing everything out and=20 ]now we are far from done it seems. We had decided to drop the Prolog verification. It=20 ]feels like we could have nailed the whole thing in time by then in a satisfactory manner=20 ]but hey... why stop the fun so early [everyone - boo now...]. No I agree. I was pretty shocked by what came back from IETF60. I'm not saying it isn't an improvement, but I did kind of feel as though the agreement we had in Lule=E5 had gone out the window... and the deadline = with it! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 1 13:17:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27138 for ; Fri, 1 Oct 2004 13:17:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRAV-0004Lb-TD for rohc-web-archive@ietf.org; Fri, 01 Oct 2004 13:26:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQKx-0004yL-FO; Fri, 01 Oct 2004 12:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDP6P-0008OX-Il for rohc@megatron.ietf.org; Fri, 01 Oct 2004 11:13:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08622 for ; Fri, 1 Oct 2004 11:13:43 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDPEs-0000oC-T5 for rohc@ietf.org; Fri, 01 Oct 2004 11:22:31 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Oct 2004 16:13:54 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2128@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'rohc@ietf.org'" Date: Fri, 1 Oct 2004 16:13:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [rohc] Consensus on Annotations, underscores and the remaining TCP/FN st uff? X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 OK then y'all let's just check that we have consensus on this. I'd hate for us to move forward here, only to find that we have a later disagreement about whether there was a consensus or not. Therefore I have put the names of the key players below each of Ghyslain points. Please indicate you agreement or not, but DO NOT include any reasoning. If this is going to work, we need just yes/no answers. If we don't have a consensus then we can continue the debate afterwards, but please not in this thread! Parties concerned (please just indicate here if you have responded or not) Ghyslain : Kristofer : Lars-Eric : Carsten : Raffles : yes Any other interested parties please add you name here ]ROHCers, ] ]Ok, I give up [more cheers!] : ) ] ]Let me summarize what comes out of the mess I seem to have ]created on the list since yesterday: ] ]1) We'll leave the underscore, we can leave the annotations in. Ghyslain : Kristofer : Lars-Eric : Carsten : Raffles : yes Any other interested parties please add you name here ] ]In addition, I will make the following changes to the FN: ] ]2) modify section 4.8.7 as follow: ] ]4.8.7. Profile-specific Encoding Methods ] ] The library of encoding methods provides a basic and ] generic set of coding methods. Some additional encodings ] specific to a particular protocol may however be needed, ] such as for methods that infer the value of a field from ] other values. These methods are defined based on the ] properties of the protocol being compressed. ] ] Profiles may define additional encoding methods; the ] scope of these methods is then local to the profile ] definition itself, and they can be used as part of the ] formal definition of the profile as any other methods ] from the library (see section xxxx). ] ] Profile-specific encoding methods must be rigorously ] defined using either the ROHC-FN syntax or in plain ] text, as long as its definition provides enough ] information to unambiguously implement the encoding ] method in the compressor and the decompressor. These ] methods should be no less complete than the methods ] provided herein. ] ] [will add the underscore notation text here] Ghyslain : Kristofer : Lars-Eric : Carsten : Raffles : yes Any other interested parties please add you name here ]3) Annotations will be clarified as to: ] - cannot be extended to mean else than number of bits for field ] - if in conflict with other part of the specs, they are not to ] prevail over the spec ] - will look like this: ] > uncompressed_format = discriminator [ 8 ], Ghyslain : Kristofer : Lars-Eric : Carsten : Raffles : yes Any other interested parties please add you name here ]4) CRC encoding method a la -03 will be reinstated and will ] now have the following signature: ] ]field ::= crc (num_bits, bit_pattern, initial_value, ] block_data_value, block_data_length) ] Ghyslain : Kristofer : Lars-Eric : Carsten : Raffles : yes Any other interested parties please add you name here ]5) Since I have the token, I will make a round of edits to ] clean up the document so that I make sure it looks like ] a specification. ] Ghyslain : Kristofer : Lars-Eric : Carsten : Raffles : yes (and apologies if my edits made it look not like a spec!) Any other interested parties please add you name here Thanks for all your inputs - it's been a breath of fresh air for me =) Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Sat Oct 2 15:21:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04234 for ; Sat, 2 Oct 2004 15:21:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDpa9-0001Vr-59 for rohc-web-archive@ietf.org; Sat, 02 Oct 2004 15:30:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDpQC-0000Bv-BY; Sat, 02 Oct 2004 15:19:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDpPD-0007CV-5y for rohc@megatron.ietf.org; Sat, 02 Oct 2004 15:18:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04092 for ; Sat, 2 Oct 2004 15:18:53 -0400 (EDT) Received: from mother.ludd.ltu.se ([130.240.16.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDpXv-0001TH-G8 for rohc@ietf.org; Sat, 02 Oct 2004 15:27:56 -0400 Received: from jymden (jymden.campus.luth.se [130.240.198.36]) by mother.ludd.ltu.se (8.12.10+Sun/8.12.10) with SMTP id i92JInPT027156; Sat, 2 Oct 2004 21:18:51 +0200 (MEST) Message-ID: <002601c4a8b4$a32ab040$24c6f082@jymden> From: "Lars-Erik Jonsson" To: "Finking, Robert" , References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2128@rsys004a.roke.co.uk> Subject: Re: [rohc] Consensus on Annotations, underscores and the remaining TCP/FN st uff? Date: Sat, 2 Oct 2004 21:18:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit > Parties concerned (please just indicate here if you have responded or not) > > Ghyslain : > Kristofer : > Lars-Erik :yes > Carsten : > Raffles : yes > Any other interested parties please add you name here > > ]ROHCers, > ] > ]Ok, I give up [more cheers!] : ) > ] > ]Let me summarize what comes out of the mess I seem to have > ]created on the list since yesterday: > ] > ]1) We'll leave the underscore, we can leave the annotations in. > > Ghyslain : > Kristofer : > Lars-Erik : no to the underscore thing, I'm ok with the annotations > Carsten : > Raffles : yes > Any other interested parties please add you name here > > ] > ]In addition, I will make the following changes to the FN: > ] > ]2) modify section 4.8.7 as follow: > ] > ]4.8.7. Profile-specific Encoding Methods > ] > ] The library of encoding methods provides a basic and > ] generic set of coding methods. Some additional encodings > ] specific to a particular protocol may however be needed, > ] such as for methods that infer the value of a field from > ] other values. These methods are defined based on the > ] properties of the protocol being compressed. > ] > ] Profiles may define additional encoding methods; the > ] scope of these methods is then local to the profile > ] definition itself, and they can be used as part of the > ] formal definition of the profile as any other methods > ] from the library (see section xxxx). > ] > ] Profile-specific encoding methods must be rigorously > ] defined using either the ROHC-FN syntax or in plain > ] text, as long as its definition provides enough > ] information to unambiguously implement the encoding > ] method in the compressor and the decompressor. These > ] methods should be no less complete than the methods > ] provided herein. > ] > ] [will add the underscore notation text here] > > Ghyslain : > Kristofer : > Lars-Erik : I'm fine with this, except for the fu**ing underscores > Carsten : > Raffles : yes > Any other interested parties please add you name here > > ]3) Annotations will be clarified as to: > ] - cannot be extended to mean else than number of bits for field > ] - if in conflict with other part of the specs, they are not to > ] prevail over the spec > ] - will look like this: > ] > uncompressed_format = discriminator [ 8 ], > > Ghyslain : > Kristofer : > Lars-Erik : yes > Carsten : > Raffles : yes > Any other interested parties please add you name here > > ]4) CRC encoding method a la -03 will be reinstated and will > ] now have the following signature: > ] > ]field ::= crc (num_bits, bit_pattern, initial_value, > ] block_data_value, block_data_length) > ] > > > Ghyslain : > Kristofer : > Lars-Erik : yes > Carsten : > Raffles : yes > Any other interested parties please add you name here > > ]5) Since I have the token, I will make a round of edits to > ] clean up the document so that I make sure it looks like > ] a specification. > ] > > Ghyslain : > Kristofer : > Lars-Erik : yes, please do > Carsten : > Raffles : yes (and apologies if my edits made it look not like a spec!) > Any other interested parties please add you name here > > Thanks for all your inputs - it's been a breath of fresh air for me =) Yes, I've really appreciated the last days discussions. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 02:24:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00823 for ; Mon, 4 Oct 2004 02:24:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEMQP-0002sJ-4j for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 02:34:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMFE-00071N-SC; Mon, 04 Oct 2004 02:22:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEMBa-0005PD-GH for rohc@megatron.ietf.org; Mon, 04 Oct 2004 02:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00054 for ; Mon, 4 Oct 2004 02:19:00 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEMKb-0002hd-GD for rohc@ietf.org; Mon, 04 Oct 2004 02:28:22 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i945HrLh026614 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Oct 2004 07:18:04 +0200 Message-ID: <4160EB95.4030207@effnet.com> Date: Mon, 04 Oct 2004 08:20:05 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars-Erik Jonsson Subject: Re: [rohc] Consensus on Annotations, underscores and the remaining TCP/FN st uff? References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2128@rsys004a.roke.co.uk> <002601c4a8b4$a32ab040$24c6f082@jymden> In-Reply-To: <002601c4a8b4$a32ab040$24c6f082@jymden> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: "Finking, Robert" , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Lars-Erik Jonsson wrote: >>Parties concerned (please just indicate here if you have responded or not) >> >>Ghyslain : >>Kristofer : yes >>Lars-Erik :yes >>Carsten : >>Raffles : yes >>Any other interested parties please add you name here >> >>]ROHCers, >>] >>]Ok, I give up [more cheers!] : ) >>] >>]Let me summarize what comes out of the mess I seem to have >>]created on the list since yesterday: >>] >>]1) We'll leave the underscore, we can leave the annotations in. >> >>Ghyslain : >>Kristofer : yes >>Lars-Erik : no to the underscore thing, I'm ok with the annotations >>Carsten : >>Raffles : yes >>Any other interested parties please add you name here >> >>] >>]In addition, I will make the following changes to the FN: >>] >>]2) modify section 4.8.7 as follow: >>] >>]4.8.7. Profile-specific Encoding Methods >>] >>] The library of encoding methods provides a basic and >>] generic set of coding methods. Some additional encodings >>] specific to a particular protocol may however be needed, >>] such as for methods that infer the value of a field from >>] other values. These methods are defined based on the >>] properties of the protocol being compressed. >>] >>] Profiles may define additional encoding methods; the >>] scope of these methods is then local to the profile >>] definition itself, and they can be used as part of the >>] formal definition of the profile as any other methods >>] from the library (see section xxxx). >>] >>] Profile-specific encoding methods must be rigorously >>] defined using either the ROHC-FN syntax or in plain >>] text, as long as its definition provides enough >>] information to unambiguously implement the encoding >>] method in the compressor and the decompressor. These >>] methods should be no less complete than the methods >>] provided herein. >>] >>] [will add the underscore notation text here] >> >>Ghyslain : >>Kristofer : yes >>Lars-Erik : I'm fine with this, except for the fu**ing underscores >>Carsten : >>Raffles : yes >>Any other interested parties please add you name here >> >>]3) Annotations will be clarified as to: >>] - cannot be extended to mean else than number of bits for field >>] - if in conflict with other part of the specs, they are not to >>] prevail over the spec >>] - will look like this: >>] > uncompressed_format = discriminator [ 8 ], >> >>Ghyslain : >>Kristofer : yes >>Lars-Erik : yes >>Carsten : >>Raffles : yes >>Any other interested parties please add you name here >> >>]4) CRC encoding method a la -03 will be reinstated and will >>] now have the following signature: >>] >>]field ::= crc (num_bits, bit_pattern, initial_value, >>] block_data_value, block_data_length) >>] >> >> >>Ghyslain : >>Kristofer : yes >>Lars-Erik : yes >>Carsten : >>Raffles : yes >>Any other interested parties please add you name here >> >>]5) Since I have the token, I will make a round of edits to >>] clean up the document so that I make sure it looks like >>] a specification. >>] >> >>Ghyslain : >>Kristofer : yes >>Lars-Erik : yes, please do >>Carsten : >>Raffles : yes (and apologies if my edits made it look not like a spec!) >>Any other interested parties please add you name here >> >>Thanks for all your inputs - it's been a breath of fresh air for me =) > > > Yes, I've really appreciated the last days discussions. > > /L-E > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 04:38:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12110 for ; Mon, 4 Oct 2004 04:38:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOV2-0000At-52 for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 04:47:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOFE-0001PR-RW; Mon, 04 Oct 2004 04:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOCM-0000mt-N8 for rohc@megatron.ietf.org; Mon, 04 Oct 2004 04:28:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10999 for ; Mon, 4 Oct 2004 04:27:55 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOLN-0007G1-OW for rohc@ietf.org; Mon, 04 Oct 2004 04:37:19 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i948RtfM024838 for ; Mon, 4 Oct 2004 10:27:55 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 10:27:54 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 10:27:54 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Ghyslain Pelletier (LU/EAB)" , "'Carsten Bormann'" , Kristofer Sandlund Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Mon, 4 Oct 2004 10:27:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 08:27:54.0127 (UTC) FILETIME=[0B5D81F0:01C4A9EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "Finking, Robert" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > > > uncompressed_format = discriminator, %[ 8 ] > > > > fine (but won't be checked by tool) > > Why can't it be checked by a tool? > Doesn't the [ 8 ] only apply to the right-hand side of the statement? I have the same question. Maybe it can't be checked by your tool because of the way you have written it, but I fail to understand why it should not be possible to write a tool that would check it. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 04:53:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13634 for ; Mon, 4 Oct 2004 04:53:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOkH-0002nI-5Y for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 05:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOY7-0003lx-0w; Mon, 04 Oct 2004 04:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOP6-0002jT-Cd for rohc@megatron.ietf.org; Mon, 04 Oct 2004 04:41:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12578 for ; Mon, 4 Oct 2004 04:41:05 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOY9-0000Wl-2m for rohc@ietf.org; Mon, 04 Oct 2004 04:50:29 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 09:41:23 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A212E@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" , "Ghyslain Pelletier (LU/EAB)" , "'Carsten Bormann'" , Kristofer Sandlund Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Mon, 4 Oct 2004 09:41:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f OK, well I guess this is a moot point now, but seeing as you're interested... The way tool writing tools work, you can easily specify comment characters. These are then completely ignored. If you want to include annotations in a comment, what you are doing is effectively getting rid of any notion of comments from the tools point of view. It can no longer throw them all away regardless, it now has to treat them all individually and check if there is any special syntax. This can quickly complete nightmare as you have to deal with any arbitrary freeform English text that you come across. What you want is a special comment, which is different from an ordinary comment, that the tool *won't* treat as a comment, but will treat as part of the main syntax, so that it can process it (and here's the important bit) just like any other syntactical element of the language. I hope this helps! Regards Raffles PS It's probably worth adding that I haven't seen or used Carsten/Eilert's tool, don't even know what language it's written in or what platform it runs on. The above are just general issues to do with parsing. -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: Monday, October 04, 2004 9:28 AM To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann'; Kristofer Sandlund Cc: Finking, Robert; 'rohc@ietf.org' Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) > > > uncompressed_format = discriminator, %[ 8 ] > > > > fine (but won't be checked by tool) > > Why can't it be checked by a tool? > Doesn't the [ 8 ] only apply to the right-hand side of the statement? I have the same question. Maybe it can't be checked by your tool because of the way you have written it, but I fail to understand why it should not be possible to write a tool that would check it. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 04:54:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13719 for ; Mon, 4 Oct 2004 04:54:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOkr-0003D9-0o for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 05:03:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOY7-0003m2-EU; Mon, 04 Oct 2004 04:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOPj-0002kd-2K for rohc@megatron.ietf.org; Mon, 04 Oct 2004 04:41:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12651 for ; Mon, 4 Oct 2004 04:41:43 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOYl-0000gN-39 for rohc@ietf.org; Mon, 04 Oct 2004 04:51:07 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i947enLh026956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Oct 2004 09:40:49 +0200 Message-ID: <41610D16.8070601@effnet.com> Date: Mon, 04 Oct 2004 10:43:02 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Subject: [rohc] ROHC-TCP packet formats - chain definitions X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Hi all, now with a hopefully more stable FN, we need to start looking at the packet formats for ROHC-TCP. Issues we had in the latest version needs to be agreed on, so I'll list some of them here with proposed solutions. - Chain concept. We've agreed on how the static/dynamic/replicate/irregular chains should work, but we've seen a number of different attempts to express them in FN, and I don't think they have really made sense from a reader's perspective. The latest attempt was to use things like let (previous (next_header):uncomp_value == 60); Since parseability is not a requirment, I think that the entire chain concept should just be expressed in English, and let the implementer assemble the chains as he sees fit. In 6.5.1, 6.5.2 and 6.5.3, we already have ASCII-pictures of all the usages of chains, so we should just expand the "profile specific part" to show which chains are present in this packet and describe how the chains are built. (by the way, it is anyway kind of silly to talk about profile specific part in a document defining only one sigle profile) - Innermost IP header. Expressing this in FN has turned out to be somewhat challenging, while it is really intuitive in english. First, we tried to use about the same thing as for the dynamic/static chains, but realized that the innermost IP header can be followed by extension headers before the TCP header, so this would require some form of state-keeping, which is unsutable in FN. So, we should skip how this is "parsed" and just express it in a simple way. The only reason we need to know if it is an innermost header is for the irregular chain (IP-ID is considered random for all but innermost header). So, we could easily make one item ipv4_irregular_innermost and ipv4_irregular_outer and describe in english when each one should be used. Some suggested text for next TCP profile version (off the top of my head so the exact wording can be worked out later): All section references refer to the -07 revision ****************************************** 6.5.1.1 (the current 6.5.1, but split the "profile specific part" into static and dynamic chain in the picture) 6.5.1.2 Constructing Static and Dynamic Chains The static chain is constructed by taking the part of a header named with a _static prefix for each header in the uncompressed packet. The first item in the chain should be taken from the header appearing first in the chain and the last item should be taken from a TCP header. For example: If a packet containing IPv6/IP6routing/IPv4/TCP is compressed to an IR packet, the static chain should be constructed by concatenating format_ipv6_static, format_route_opt_static, format_ipv4_static, format_tcp_static from these headers. The dynamic chain is constructed analogously as the static chain. 6.5.2.1 (the current 6.5.2, but replace the "profile specific part" with "Replicate Chain") 6.5.2.2 Constructing the Replicate Chain The replicate chain in the IR-CR packet is constructed analogously to the static and dynamic chains described in 6.5.1.1 so that one item in the replicate chain is taken from each header in the uncompressed packet. It should be noted that there are often multiple different replicate chain items to choose from for each header. The choice of which to use is an implementation issue based on the replicate strategy of the compressor. 6.5.3.1 (the current 6.5.3) 6.5.3.2 Constructing the Header Chain Irregular Part The irregular chain of all compressed packet formats is constructed analogously to the static and dynamic chains described in 6.5.1.2 so that one item in the irregular chain is taken from each header in the uncompressed packet. There is one additional concept that the compressor needs to notice though. Since the innermost IP header is part of the base header, the innermost IP header has a different irregular chain than all other IP headers. Therefore, both the IPv4 header and the IPv6 header has two different irregular chain items, where one is prefixed by innermost_ and the other is prefixed outer_. The compressor should only choose the _innermost item if there are no more IP headers between this header and the TCP header. 6.5.3.3 TCP Options Irregular Part Apart from the Header Chain Irregular Part, the TCP Options Irregular Part is also included in the general format for a compressed TCP header. This field should be constructed by taking an item postfixed by _irregular for each TCP option present in the uncompressed packet in the order that they appear. For example: The TCP options list contains NOP, NOP and EOL options. Then the TCP Options Irregular Part is constructed from format_nop_irregular, format_nop_irregular and format_eol_irregular. ********************************************* This would mean that we remove sections 6.6.7-6.6.10 in -07, which I think makes sense since all this stuff with "previous" etc is only useful from a parsing perspective, while I find it only confusing from an implementer's perspective. I can probably try to make a revised version of the packet formats later this week if this is the way we decide to go. Let the flaming begin. /Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 04:55:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13901 for ; Mon, 4 Oct 2004 04:55:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOmJ-0003Ey-3D for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 05:05:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOap-0004H2-73; Mon, 04 Oct 2004 04:53:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOXV-0003d3-Vh for rohc@megatron.ietf.org; Mon, 04 Oct 2004 04:49:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13382 for ; Mon, 4 Oct 2004 04:49:47 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOgY-0002Cl-OL for rohc@ietf.org; Mon, 04 Oct 2004 04:59:11 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i947mqLh026975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Oct 2004 09:48:53 +0200 Message-ID: <41610EF9.6090603@effnet.com> Date: Mon, 04 Oct 2004 10:51:05 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A212E@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A212E@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: "'Carsten Bormann'" , "'rohc@ietf.org'" , "'Lars-Erik Jonsson \(LU/EAB\)'" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit To me, this is a non-valid argument. I've writen a few parsers in my life, and I cannot see why any parser cannot have one treatment (use this) for a comment starting with %[ and another one (throw this away) for a comment that starts with % followed by anything other than [ . Not that it matters to me what signs we use for comments/annotations, but I cannot for the life of me understand why this would be "[a] complete nightmare". We've said that we would not allow extensions to the annotation syntax, so you will never have to check against "arbitrary freeform English text". Right? /Kristofer Sandlund, Effnet AB Finking, Robert wrote: > OK, well I guess this is a moot point now, but seeing as you're interested... > > The way tool writing tools work, you can easily specify comment characters. These are then completely ignored. If you want to include annotations in a comment, what you are doing is effectively getting rid of any notion of comments from the tools point of view. It can no longer throw them all away regardless, it now has to treat them all individually and check if there is any special syntax. This can quickly complete nightmare as you have to deal with any arbitrary freeform English text that you come across. What you want is a special comment, which is different from an ordinary comment, that the tool *won't* treat as a comment, but will treat as part of the main syntax, so that it can process it (and here's the important bit) just like any other syntactical element of the language. > > I hope this helps! > > Regards > > Raffles > > PS It's probably worth adding that I haven't seen or used Carsten/Eilert's tool, don't even know what language it's written in or what platform it runs on. The above are just general issues to do with parsing. > > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] > Sent: Monday, October 04, 2004 9:28 AM > To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann'; Kristofer Sandlund > Cc: Finking, Robert; 'rohc@ietf.org' > Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) > > > >>>> uncompressed_format = discriminator, %[ 8 ] >>> >>>fine (but won't be checked by tool) >> >>Why can't it be checked by a tool? >>Doesn't the [ 8 ] only apply to the right-hand side of the statement? > > > I have the same question. Maybe it can't be checked by your tool > because of the way you have written it, but I fail to understand > why it should not be possible to write a tool that would check it. > > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 05:08:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14654 for ; Mon, 4 Oct 2004 05:08:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOyL-00043y-T8 for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 05:17:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOgW-00057o-Js; Mon, 04 Oct 2004 04:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOef-0004tC-Oe for rohc@megatron.ietf.org; Mon, 04 Oct 2004 04:57:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14021 for ; Mon, 4 Oct 2004 04:57:11 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOni-0003Fu-P4 for rohc@ietf.org; Mon, 04 Oct 2004 05:06:35 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 09:57:27 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2130@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Kristofer Sandlund'" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Mon, 4 Oct 2004 09:57:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "'Carsten Bormann'" , "'rohc@ietf.org'" , "'Lars-Erik Jonsson \(LU/EAB\)'" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 I guess it depends if you're hand coding the parser or not, and also whether you want to stick to single character lookahead or not (which makes things a lot simpler of course). Probably I better let Carsten answer this anyway! Cheers Raffles -----Original Message----- From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] Sent: Monday, October 04, 2004 9:51 AM To: Finking, Robert Cc: 'Lars-Erik Jonsson (LU/EAB)'; Ghyslain Pelletier (LU/EAB); 'Carsten Bormann'; 'rohc@ietf.org' Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) To me, this is a non-valid argument. I've writen a few parsers in my life, and I cannot see why any parser cannot have one treatment (use this) for a comment starting with %[ and another one (throw this away) for a comment that starts with % followed by anything other than [ . Not that it matters to me what signs we use for comments/annotations, but I cannot for the life of me understand why this would be "[a] complete nightmare". We've said that we would not allow extensions to the annotation syntax, so you will never have to check against "arbitrary freeform English text". Right? /Kristofer Sandlund, Effnet AB Finking, Robert wrote: > OK, well I guess this is a moot point now, but seeing as you're interested... > > The way tool writing tools work, you can easily specify comment characters. These are then completely ignored. If you want to include annotations in a comment, what you are doing is effectively getting rid of any notion of comments from the tools point of view. It can no longer throw them all away regardless, it now has to treat them all individually and check if there is any special syntax. This can quickly complete nightmare as you have to deal with any arbitrary freeform English text that you come across. What you want is a special comment, which is different from an ordinary comment, that the tool *won't* treat as a comment, but will treat as part of the main syntax, so that it can process it (and here's the important bit) just like any other syntactical element of the language. > > I hope this helps! > > Regards > > Raffles > > PS It's probably worth adding that I haven't seen or used Carsten/Eilert's tool, don't even know what language it's written in or what platform it runs on. The above are just general issues to do with parsing. > > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] > Sent: Monday, October 04, 2004 9:28 AM > To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann'; Kristofer Sandlund > Cc: Finking, Robert; 'rohc@ietf.org' > Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) > > > >>>> uncompressed_format = discriminator, %[ 8 ] >>> >>>fine (but won't be checked by tool) >> >>Why can't it be checked by a tool? >>Doesn't the [ 8 ] only apply to the right-hand side of the statement? > > > I have the same question. Maybe it can't be checked by your tool > because of the way you have written it, but I fail to understand > why it should not be possible to write a tool that would check it. > > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 05:18:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15479 for ; Mon, 4 Oct 2004 05:18:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEP7h-0004go-M5 for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 05:27:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOuD-0006hC-FS; Mon, 04 Oct 2004 05:13:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEOqh-00061M-Rq for rohc@megatron.ietf.org; Mon, 04 Oct 2004 05:09:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14797 for ; Mon, 4 Oct 2004 05:09:37 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOza-00045h-Ki for rohc@ietf.org; Mon, 04 Oct 2004 05:19:01 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9499SRU030433 for ; Mon, 4 Oct 2004 11:09:28 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 11:09:28 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 11:09:24 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kristofer Sandlund'" , rohc@ietf.org Subject: RE: [rohc] ROHC-TCP packet formats - chain definitions Date: Mon, 4 Oct 2004 11:09:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 09:09:28.0079 (UTC) FILETIME=[D9E061F0:01C4A9F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 > - Chain concept. We've agreed on how the > static/dynamic/replicate/irregular chains should work, > but we've seen a number of different attempts to express > them in FN, and I don't think they have really made > sense from a reader's perspective. Since parseability is > not a requirment, I think that the entire chain concept > should just be expressed in English, and let the > implementer assemble the chains as he sees fit. Fully agree! > In 6.5.1, 6.5.2 and 6.5.3, we already have ASCII-pictures > of all the usages of chains, so we should just expand the > "profile specific part" to show which chains are present > in this packet and describe how the chains are built. > (by the way, it is anyway kind of silly to talk about > profile specific part in a document defining only one > sigle profile) Yes, that is a good point, let's fix that terminology. > - Innermost IP header. Expressing this in FN has turned > out to be somewhat challenging, while it is really' > intuitive in english. First, we tried to use about the > same thing as for the dynamic/static chains, but realized > that the innermost IP header can be followed by extension > headers before the TCP header, so this would require some > form of state-keeping, which is unsutable in FN. So, we > should skip how this is "parsed" and just express it in a > simple way. The only reason we need to know if it is an > innermost header is for the irregular chain (IP-ID is > considered random for all but innermost header). So, we > could easily make one item ipv4_irregular_innermost and > ipv4_irregular_outer and describe in english when each > one should be used. Sounds reasonable to me! > I can probably try to make a revised version of the packet > formats later this week if this is the way we decide to go. That would be appreciated! > Let the flaming begin. I'll leave that to others! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 05:31:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16390 for ; Mon, 4 Oct 2004 05:31:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPKR-0005cW-0N for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 05:40:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEP9b-0000cG-9M; Mon, 04 Oct 2004 05:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEP2d-0007lX-LQ for rohc@megatron.ietf.org; Mon, 04 Oct 2004 05:21:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15893 for ; Mon, 4 Oct 2004 05:21:56 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPBg-0004ms-N4 for rohc@ietf.org; Mon, 04 Oct 2004 05:31:21 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i949LZWO002647; Mon, 4 Oct 2004 11:21:36 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2130@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2130@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Mon, 4 Oct 2004 11:21:33 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" , "Ghyslain Pelletier \(LU/EAB\)" , "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit On Oct 04 2004, at 10:57 Uhr, Finking, Robert wrote: > I guess it depends if you're hand coding the parser or not, and also > whether > you want to stick to single character lookahead or not (which makes > things a > lot simpler of course). > > Probably I better let Carsten answer this anyway! Our tool is written in Prolog. Prolog DCGs can do unlimited look-ahead (without these we would never have been able to parse the near-unparseable Lulea syntax...). It is unsavory, but not particularly hard to implement, to change the syntax to look for special comments after delimiter symbols and relate the contents of these comments to what was before the delimiter symbol. I'll certainly bow to any rough consensus that emerges. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 05:38:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16938 for ; Mon, 4 Oct 2004 05:38:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPS1-0006Jh-3U for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 05:48:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPG6-0001VV-WB; Mon, 04 Oct 2004 05:35:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPEJ-0001KN-L4 for rohc@megatron.ietf.org; Mon, 04 Oct 2004 05:34:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16623 for ; Mon, 4 Oct 2004 05:34:00 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPNB-0005m1-KM for rohc@ietf.org; Mon, 04 Oct 2004 05:43:25 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i949XoRU006134 for ; Mon, 4 Oct 2004 11:33:50 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 11:33:50 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 11:33:50 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Carsten Bormann'" , "Finking, Robert" Subject: RE: [rohc] RE: Annotoations Date: Mon, 4 Oct 2004 11:33:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 09:33:50.0297 (UTC) FILETIME=[416D2490:01C4A9F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "'rohc@ietf.org'" , "'Kristofer Sandlund'" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 > On Oct 04 2004, at 10:57 Uhr, Finking, Robert wrote: > > > I guess it depends if you're hand coding the parser or not, > > and also whether you want to stick to single character > > lookahead or not (which makes things a lot simpler of course). > > > > Probably I better let Carsten answer this anyway! > > Our tool is written in Prolog. > Prolog DCGs can do unlimited look-ahead (without these we would never > have been able to parse the near-unparseable Lulea syntax...). > > It is unsavory, but not particularly hard to implement, to change > the syntax to look for special comments after delimiter symbols > and relate the contents of these comments to what was before the > delimiter symbol. > I'll certainly bow to any rough consensus that emerges. Then I propose that we do specify annotations that can be used for verification purposes, but as a "formalized comment", i.e. based on the following format: uncompressed_format = discriminator, %[ 8 ] tcp.seq_number, %[ 32 ] tcp.flags.ecn, %[ 2 ] The mechanism would then be present for us to use for verification tools, while still not being part of the actual notation. To me, this looks like a reasonable compromise, or? /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 05:58:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18747 for ; Mon, 4 Oct 2004 05:58:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPl9-0001FS-FB for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 06:08:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPYV-0003au-P3; Mon, 04 Oct 2004 05:54:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPPg-0002Td-0T for rohc@megatron.ietf.org; Mon, 04 Oct 2004 05:45:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17550 for ; Mon, 4 Oct 2004 05:45:45 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPYi-0007Vu-47 for rohc@ietf.org; Mon, 04 Oct 2004 05:55:09 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i949jjRU010808 for ; Mon, 4 Oct 2004 11:45:45 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 11:45:44 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 11:45:44 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "Lars-Erik Jonsson (LU/EAB)" , "'Carsten Bormann'" , "'Finking, Robert'" Subject: RE: [rohc] RE: Annotoations Date: Mon, 4 Oct 2004 11:45:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 09:45:44.0153 (UTC) FILETIME=[EAEAEC90:01C4A9F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hold on, I have proposed that earlier... I understand your mail as a bit contradictive: > Then I propose that we do specify annotations that can be used > for verification purposes, but as a "formalized comment", i.e. > The mechanism would then be present for us to use for verification > tools, while still not being part of the actual notation. How do you suggest that we specify "formalized comments" without being part of the FN? I suggested that the ROHC-FN draft removes anything about notation and that we had a note about such annotations being used inside comments into the TCP draft, in the section where we start specifying packet formats. Is that how you suggest it??? Not that I care anymore though. ///Ghyslain > > Then I propose that we do specify annotations that can be used > for verification purposes, but as a "formalized comment", i.e. > based on the following format: > > uncompressed_format = discriminator, %[ 8 ] > tcp.seq_number, %[ 32 ] > tcp.flags.ecn, %[ 2 ] > > The mechanism would then be present for us to use for verification > tools, while still not being part of the actual notation. To me, > this looks like a reasonable compromise, or? > > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 06:00:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18901 for ; Mon, 4 Oct 2004 06:00:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPmb-0001H1-0d for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 06:09:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPYW-0003br-IY; Mon, 04 Oct 2004 05:54:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPPw-0002Wd-QQ for rohc@megatron.ietf.org; Mon, 04 Oct 2004 05:46:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17584 for ; Mon, 4 Oct 2004 05:46:01 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPYp-0007W2-QO for rohc@ietf.org; Mon, 04 Oct 2004 05:55:26 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i949jqWR001996 for ; Mon, 4 Oct 2004 11:45:52 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 11:45:53 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 11:45:52 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Carsten Bormann'" , "Finking, Robert" Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Mon, 4 Oct 2004 11:45:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 09:45:53.0405 (UTC) FILETIME=[F06EAAD0:01C4A9F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "'rohc@ietf.org'" , "'Kristofer Sandlund'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Comments Inline... ///Ghyslain > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: den 4 oktober 2004 11:22 > To: Finking, Robert > Cc: Carsten Bormann; 'rohc@ietf.org'; 'Kristofer Sandlund'; Ghyslain > Pelletier (LU/EAB); Lars-Erik Jonsson (LU/EAB) > Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - > Wednesd ay's update ) > > > On Oct 04 2004, at 10:57 Uhr, Finking, Robert wrote: > > > I guess it depends if you're hand coding the parser or not, > and also > > whether > > you want to stick to single character lookahead or not (which makes > > things a > > lot simpler of course). > > > > Probably I better let Carsten answer this anyway! > > Our tool is written in Prolog. > Prolog DCGs can do unlimited look-ahead (without these we would never > have been able to parse the near-unparseable Lulea syntax...). > > It is unsavory, but not particularly hard to implement, to change the > syntax to look for special comments after delimiter symbols > and relate > the contents of these comments to what was before the > delimiter symbol. > I'll certainly bow to any rough consensus that emerges. I know I am not going to impress anyone with this, but my printer-like understanding of parsing and design of parsing tools come from Lex/YaCC (I kwnow, it's a dinosaur whose asteroid still hasn't fallen - every lol at me!) that I have used 10 years ago to program an interpreter language specialised in automation of tele switch testing for E///. I sort of remember Lex being capable of doing a single look-ahead to e.g. conciliate comments and the line continuation character, and could not see that the situation mentioned here was a problem for parser design in general... But then, I don't consider stuff I even did last month as recent enough to based my understanding of things onto... but it's good to know that I did not seemed to be that wrong about this all along. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 07:42:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26363 for ; Mon, 4 Oct 2004 07:42:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CERNR-0000TJ-Bs for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 07:51:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CERCQ-0007wA-Ag; Mon, 04 Oct 2004 07:40:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CER7k-0006p1-Rt for rohc@megatron.ietf.org; Mon, 04 Oct 2004 07:35:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25846 for ; Mon, 4 Oct 2004 07:35:23 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CERGc-0008J8-ND for rohc@ietf.org; Mon, 04 Oct 2004 07:44:47 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i94BZARU017729 for ; Mon, 4 Oct 2004 13:35:10 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 13:35:10 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 13:35:06 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Ghyslain Pelletier (LU/EAB)" , "'Carsten Bormann'" , "'Finking, Robert'" Subject: RE: [rohc] RE: Annotoations Date: Mon, 4 Oct 2004 13:34:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 11:35:10.0919 (UTC) FILETIME=[3503E570:01C4AA06] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 > Hold on, I have proposed that earlier... > I understand your mail as a bit contradictive: > > > Then I propose that we do specify annotations that can be used > > for verification purposes, but as a "formalized comment", i.e. > > > The mechanism would then be present for us to use for verification > > tools, while still not being part of the actual notation. > > How do you suggest that we specify "formalized comments" > without being part of the FN? Well I thought we might define the annotation format in the FN, although it would be used (if used) as part of comments. With this being defined within the FN, my idea was that the format would still be more generally defined. But... (see below) > I suggested that the ROHC-FN draft removes anything about > notation and that we had a note about such annotations being > used inside comments into the TCP draft, in the section where > we start specifying packet formats. Is that how you suggest it??? ...when thinking more about this, I tend to agree with you that it would actually make more sense to define such comment-annotations within a profile where one would make use of them, as it would have no normative meaning to define it in the FN. The same conclusion as for the underscore escape character for methods. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 08:09:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28765 for ; Mon, 4 Oct 2004 08:09:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CERnR-0003IU-SU for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 08:18:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CERWa-0003Rt-Ar; Mon, 04 Oct 2004 08:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CERLr-0001Na-GI for rohc@megatron.ietf.org; Mon, 04 Oct 2004 07:49:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27062 for ; Mon, 4 Oct 2004 07:49:57 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CERUl-0000xc-V5 for rohc@ietf.org; Mon, 04 Oct 2004 07:59:22 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i94BnW2q005577; Mon, 4 Oct 2004 13:49:33 +0200 (MEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74492A5F-15FB-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: Annotoations Date: Mon, 4 Oct 2004 13:49:31 +0200 To: "Lars-Erik Jonsson (LU/EAB)" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'Kristofer Sandlund'" , Carsten Bormann , "'rohc@ietf.org'" , "'Finking, Robert'" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit >> I suggested that the ROHC-FN draft removes anything about >> notation Really? ;-) >> and that we had a note about such annotations being >> used inside comments into the TCP draft, in the section where >> we start specifying packet formats. Is that how you suggest it??? > > ...when thinking more about this, I tend to agree with you that it > would actually make more sense to define such comment-annotations > within a profile where one would make use of them, as it would have > no normative meaning to define it in the FN. As we are currently defining FN specifically for TCP, I don't have a strong feeling on what we put where. FN will have to be updated for just about any other profile we do in it, anyway, and we can decide what we want to move back from TCP into FN when we do this. > The same conclusion as > for the underscore escape character for methods. At some point, the TCP draft should have a section that summarizes/lists what methods are defined in English. This section might be phrased like this: ipv4_inferred_dodo === "section 4.7"; udp_inferred_glorp === "section 4.9"; An FN processor could take this as a hint that these methods are defined in English. Look, Ma, no (leading) underscores. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 08:09:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28813 for ; Mon, 4 Oct 2004 08:09:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CERnq-0003JL-5u for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 08:18:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CERXC-0003sH-Ki; Mon, 04 Oct 2004 08:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CERUQ-0002aW-Tc for rohc@megatron.ietf.org; Mon, 04 Oct 2004 07:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27761 for ; Mon, 4 Oct 2004 07:58:49 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CERdV-0001c7-3q for rohc@ietf.org; Mon, 04 Oct 2004 08:08:13 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i94BwnWR009587 for ; Mon, 4 Oct 2004 13:58:49 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 13:58:48 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 13:58:46 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Carsten Bormann'" Subject: RE: [rohc] RE: Annotoations Date: Mon, 4 Oct 2004 13:58:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 11:58:48.0981 (UTC) FILETIME=[823EFC50:01C4AA09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "'Finking, Robert'" , "'rohc@ietf.org'" , "'Kristofer Sandlund'" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f > At some point, the TCP draft should have a section that > summarizes/lists what methods are defined in English. > This section might be phrased like this: > > ipv4_inferred_dodo === "section 4.7"; > udp_inferred_glorp === "section 4.9"; > > An FN processor could take this as a hint that these methods are > defined in English. Look, Ma, no (leading) underscores. Looks good!! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 08:39:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00784 for ; Mon, 4 Oct 2004 08:39:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CESGp-0000P1-FB for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 08:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CES3J-0001gb-A5; Mon, 04 Oct 2004 08:34:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CES36-0001cV-1u for rohc@megatron.ietf.org; Mon, 04 Oct 2004 08:34:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00532 for ; Mon, 4 Oct 2004 08:34:36 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CESC7-0007oW-Rt for rohc@ietf.org; Mon, 04 Oct 2004 08:44:02 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i94CYVRU006897 for ; Mon, 4 Oct 2004 14:34:31 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 14:34:31 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 14:34:28 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Carsten Bormann'" , "Lars-Erik Jonsson (LU/EAB)" Subject: RE: [rohc] RE: Annotoations Date: Mon, 4 Oct 2004 14:34:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Oct 2004 12:34:31.0489 (UTC) FILETIME=[7F47C310:01C4AA0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "'Finking, Robert'" , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 > >> I suggested that the ROHC-FN draft removes anything about > >> notation > > Really? ;-) > It's a freudian typo : ) I saw that only after having sent the mail, and I thought no one would too evil to point the flagrant mispelling of "annotations"... Funny typo indeed ; ) /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 08:54:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01757 for ; Mon, 4 Oct 2004 08:54:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CESVn-000381-7A for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 09:04:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CESLa-0003fy-R3; Mon, 04 Oct 2004 08:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CESIb-00037j-90 for rohc@megatron.ietf.org; Mon, 04 Oct 2004 08:50:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01536 for ; Mon, 4 Oct 2004 08:50:39 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CESRg-0001zv-16 for rohc@ietf.org; Mon, 04 Oct 2004 09:00:04 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 13:50:58 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2138@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'rohc@ietf.org'" Date: Mon, 4 Oct 2004 13:50:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [rohc] FN: we're doing it again... X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1923868229==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1923868229== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AA10.C33D35C6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4AA10.C33D35C6 Content-Type: text/plain Guys, what's going on here? We all spent blood sweat and tears, not to mention large numbers of e-mails getting to a consensus on both these issues. I must admit I'm making the assumption here that Ghyslain agrees with all his own suggestions, but if so we have consensus. Why on earth are we spending more time going over alternative possibilities? Apart from the time spent discussing them, any changes we make are going to make more work. Ghyslain's current suggestions are great in that they require minimal change to the document. Presumably the same applies to Carsten's tool? I just don't get it - it's not like we're miles ahead of schedule. We need to get this finished. We've got consensus. Let's move on! Raffles PS yes, I have got more funding this week after all =) ------_=_NextPart_001_01C4AA10.C33D35C6 Content-Type: text/html Message
Guys, what's going on here? We all spent blood sweat and tears, not to mention large numbers of e-mails getting to a consensus on both these issues. I must admit I'm making the assumption here that Ghyslain agrees with all his own suggestions, but if so we have consensus. Why on earth are we spending more time going over alternative possibilities? Apart from the time spent discussing them, any changes we make are going to make more work. Ghyslain's current suggestions are great in that they require minimal change to the document. Presumably the same applies to Carsten's tool?
 
 
I just don't get it - it's not like we're miles ahead of schedule. We need to get this finished. We've got consensus. Let's move on!
 
Raffles
 
PS yes, I have got more funding this week after all =)
------_=_NextPart_001_01C4AA10.C33D35C6-- --===============1923868229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1923868229==-- From rohc-bounces@ietf.org Mon Oct 4 09:11:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03233 for ; Mon, 4 Oct 2004 09:11:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CESlW-0005qu-J8 for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 09:20:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CESbw-0005TJ-63; Mon, 04 Oct 2004 09:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CESYm-00052n-1Z for rohc@megatron.ietf.org; Mon, 04 Oct 2004 09:07:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02645 for ; Mon, 4 Oct 2004 09:07:21 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEShq-0005H9-Gh for rohc@ietf.org; Mon, 04 Oct 2004 09:16:47 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i94D7FiB022511; Mon, 4 Oct 2004 15:07:16 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2128@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2128@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4F4B8930-1606-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] Consensus on Annotations, underscores and the remaining TCP/FN st uff? Date: Mon, 4 Oct 2004 15:07:14 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit > OK then y'all let's just check that we have consensus on this. I'd > hate for > us to move forward here, only to find that we have a later disagreement > about whether there was a consensus or not. Therefore I have put the > names > of the key players below each of Ghyslain points. Please indicate you > agreement or not, but DO NOT include any reasoning. If this is going to > work, we need just yes/no answers. If we don't have a consensus then > we can > continue the debate afterwards, but please not in this thread! > > Parties concerned (please just indicate here if you have responded or > not) > > Ghyslain : > Kristofer : > Lars-Eric : > Carsten : yes > Raffles : yes > Any other interested parties please add you name here > > ]ROHCers, > ] > ]Ok, I give up [more cheers!] : ) > ] > ]Let me summarize what comes out of the mess I seem to have > ]created on the list since yesterday: > ] > ]1) We'll leave the underscore, we can leave the annotations in. > > Ghyslain : > Kristofer : > Lars-Eric : > Carsten : yes, except that we now have proposals that seem to have an even larger consensus. > Raffles : yes > Any other interested parties please add you name here > > ] > ]In addition, I will make the following changes to the FN: > ] > ]2) modify section 4.8.7 as follow: > ] > ]4.8.7. Profile-specific Encoding Methods > ] > ] The library of encoding methods provides a basic and > ] generic set of coding methods. Some additional encodings > ] specific to a particular protocol may however be needed, > ] such as for methods that infer the value of a field from > ] other values. These methods are defined based on the > ] properties of the protocol being compressed. > ] > ] Profiles may define additional encoding methods; the > ] scope of these methods is then local to the profile > ] definition itself, and they can be used as part of the > ] formal definition of the profile as any other methods > ] from the library (see section xxxx). > ] > ] Profile-specific encoding methods must be rigorously > ] defined using either the ROHC-FN syntax or in plain > ] text, as long as its definition provides enough > ] information to unambiguously implement the encoding > ] method in the compressor and the decompressor. These > ] methods should be no less complete than the methods > ] provided herein. > ] > ] [will add the underscore notation text here] > > Ghyslain : > Kristofer : > Lars-Eric : > Carsten : I can live with the text above. I don't care about underscores vs. declarations of non-formal definitions -- the information should be there. > Raffles : yes > Any other interested parties please add you name here > > ]3) Annotations will be clarified as to: > ] - cannot be extended to mean else than number of bits for field > ] - if in conflict with other part of the specs, they are not to > ] prevail over the spec > ] - will look like this: > ] > uncompressed_format = discriminator [ 8 ], > > Ghyslain : > Kristofer : > Lars-Eric : > Carsten : yes, again, we have another proposal. > Raffles : yes > Any other interested parties please add you name here > > ]4) CRC encoding method a la -03 will be reinstated and will > ] now have the following signature: > ] > ]field ::= crc (num_bits, bit_pattern, initial_value, > ] block_data_value, block_data_length) > ] > > > Ghyslain : > Kristofer : > Lars-Eric : > Carsten : yes, please. > Raffles : yes > Any other interested parties please add you name here > > ]5) Since I have the token, I will make a round of edits to > ] clean up the document so that I make sure it looks like > ] a specification. > ] > > Ghyslain : > Kristofer : > Lars-Eric : > Carsten : Yes, please > Raffles : yes (and apologies if my edits made it look not like a > spec!) > Any other interested parties please add you name here > > Thanks for all your inputs - it's been a breath of fresh air for me =) > > Raffles > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 09:36:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04727 for ; Mon, 4 Oct 2004 09:36:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CET9a-0001mk-SB for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 09:45:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CESwO-0007bC-Ig; Mon, 04 Oct 2004 09:31:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CESuH-0007L9-EK for rohc@megatron.ietf.org; Mon, 04 Oct 2004 09:29:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04335 for ; Mon, 4 Oct 2004 09:29:35 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CET3C-0000gw-8g for rohc@ietf.org; Mon, 04 Oct 2004 09:39:01 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i94DTPRU025396 for ; Mon, 4 Oct 2004 15:29:25 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 15:29:24 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 15:29:19 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Finking, Robert'" , "'rohc@ietf.org'" Subject: RE: [rohc] FN: we're doing it again... Date: Mon, 4 Oct 2004 15:26:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-OriginalArrivalTime: 04 Oct 2004 13:29:25.0469 (UTC) FILETIME=[2AA538D0:01C4AA16] X-Spam-Score: 0.9 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1099433275==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1099433275== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AA15.C36F6277" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4AA15.C36F6277 Content-Type: text/plain; charset="iso-8859-1" Lesson to learn: Don't try to judge (enforce) consensus before you actually have it. To me, it seems like todays discussions have actually brought us closer to some kind of consensus on these issues, by starting to understand each other. I might be wrong if you disagree with what has been said today, just let us know if that is the case. Speaking only for myself, I know that I might sometimes suggest things that I will later argue against, if input from others makes me change my mind. That's what might happen as a result of open discussions. /L-E -----Original Message----- From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Finking, Robert Sent: den 4 oktober 2004 14:51 To: 'rohc@ietf.org' Subject: [rohc] FN: we're doing it again... Guys, what's going on here? We all spent blood sweat and tears, not to mention large numbers of e-mails getting to a consensus on both these issues. I must admit I'm making the assumption here that Ghyslain agrees with all his own suggestions, but if so we have consensus. Why on earth are we spending more time going over alternative possibilities? Apart from the time spent discussing them, any changes we make are going to make more work. Ghyslain's current suggestions are great in that they require minimal change to the document. Presumably the same applies to Carsten's tool? I just don't get it - it's not like we're miles ahead of schedule. We need to get this finished. We've got consensus. Let's move on! Raffles ------_=_NextPart_001_01C4AA15.C36F6277 Content-Type: text/html; charset="iso-8859-1" Message
Lesson to learn: Don't try to judge (enforce) consensus before you actually have it.
 
To me, it seems like todays discussions have actually brought us closer to some kind of consensus on these issues, by starting to understand each other. I might be wrong if you disagree with what has been said today,
just let us know if that is the case.
 
Speaking only for myself, I know that I might sometimes suggest things that I will later argue against, if input from others makes me change my mind. That's what might happen as a result of open discussions.
 
/L-E
-----Original Message-----
From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Finking, Robert
Sent: den 4 oktober 2004 14:51
To: 'rohc@ietf.org'
Subject: [rohc] FN: we're doing it again...

Guys, what's going on here? We all spent blood sweat and tears, not to mention large numbers of e-mails getting to a consensus on both these issues. I must admit I'm making the assumption here that Ghyslain agrees with all his own suggestions, but if so we have consensus. Why on earth are we spending more time going over alternative possibilities? Apart from the time spent discussing them, any changes we make are going to make more work. Ghyslain's current suggestions are great in that they require minimal change to the document. Presumably the same applies to Carsten's tool?
 
 
I just don't get it - it's not like we're miles ahead of schedule. We need to get this finished. We've got consensus. Let's move on!
 
Raffles
------_=_NextPart_001_01C4AA15.C36F6277-- --===============1099433275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1099433275==-- From rohc-bounces@ietf.org Mon Oct 4 10:31:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09727 for ; Mon, 4 Oct 2004 10:31:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEU1E-0002kV-GT for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 10:40:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETjq-0001Qd-Ro; Mon, 04 Oct 2004 10:22:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETes-00004x-Fb for rohc@megatron.ietf.org; Mon, 04 Oct 2004 10:17:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08273 for ; Mon, 4 Oct 2004 10:17:44 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CETnx-0000XQ-B7 for rohc@ietf.org; Mon, 04 Oct 2004 10:27:10 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 15:17:58 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A213C@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'rohc@ietf.org'" Subject: RE: [rohc] FN: we're doing it again... Date: Mon, 4 Oct 2004 15:17:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Hi L-E, ]Lesson to learn: Don't try to judge (enforce) consensus before you=20 ]actually have it. Hmm, OK, point taken - thanks =3D) For the record I wasn't trying to judge anything. Although I'm new to = all this stuff I've quickly picked up that at the IETF it's not uncommon = for old discussions to get revisited and re-revisited e.g. by watching Ghyslain = and Zhigang ;-). Since I thought I would have no money this week to = continue making these posts, I just figured it would be good to check if there = was a consensus on what Ghyslain said, so that I didn't end up coming back in = a month's time to find out we hadn't actually made any valid decisions. = Also, it's worth noting that at the time of posting my below mail, we did = have consensus on paper. However we seem to have opened it up again, which, ironically is what I was trying to avoid. ]To me, it seems like today's discussions have actually brought us = closer to ]some kind of consensus on these issues, by starting to understand each = ]other. I might be wrong if you disagree with what has been said today, = ]just let us know if that is the case. I must admit that I don't quite like the new technical proposals as = much as what we had last week, but I'm not going to barf on them. The thing I disagree with is carrying on spending time on this unnecessarily. As = you may recall from my mail I sent out before we started any of this, the most important thing to me is to expedite the whole process. We've been = trying and failing to do that since before Lule=E5, and we're in danger of = continuing to fail, because we're not focusing on getting this done, we're = focusing on getting it perfect. ] ]Speaking only for myself, I know that I might sometimes suggest things = that ]I will later argue against, if input from others makes me change my = mind.=20 ]That's what might happen as a result of open discussions. That's great! It's nice to know we can be truly objective (a rare = thing) =3D) But we're miles behind schedule here. The technical issues are = secondary; they're not show-stoppers. We're spending time on minutiae. Even with = no changes, the draft as it stands is fine IMHO. Let's just get on with finishing the TCP profile. I'm sure the FN issues that come out of that = will dwarf the consideration of whether we use underscores or "import" type statements for external encoding methods! Anyway too much of a rant again - sorry. The point is that I'm happy = with pretty much anything as long as we can get a consensus and move on. Cheers Raffles -----Original Message----- From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Finking, Robert Sent: den 4 oktober 2004 14:51 To: 'rohc@ietf.org' Subject: [rohc] FN: we're doing it again... Guys, what's going on here? We all spent blood sweat and tears, not to mention large numbers of e-mails getting to a consensus on both these issues. I must admit I'm making the assumption here that Ghyslain = agrees with all his own suggestions, but if so we have consensus. Why on earth = are we spending more time going over alternative possibilities? Apart from = the time spent discussing them, any changes we make are going to make more = work. Ghyslain's current suggestions are great in that they require minimal = change to the document. Presumably the same applies to Carsten's tool? I just don't get it - it's not like we're miles ahead of schedule. We = need to get this finished. We've got consensus. Let's move on! Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 11:05:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12211 for ; Mon, 4 Oct 2004 11:05:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEUXh-0007e6-SF for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 11:14:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUNQ-0007nn-6k; Mon, 04 Oct 2004 11:03:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUKL-0007Qf-Dd for rohc@megatron.ietf.org; Mon, 04 Oct 2004 11:00:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11956 for ; Mon, 4 Oct 2004 11:00:34 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEUTH-00075N-BO for rohc@ietf.org; Mon, 04 Oct 2004 11:10:02 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i94F0MRU028375 for ; Mon, 4 Oct 2004 17:00:25 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 17:00:22 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 17:00:21 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Finking, Robert'" Subject: RE: [rohc] FN: we're doing it again... Date: Mon, 4 Oct 2004 17:00:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 04 Oct 2004 15:00:22.0126 (UTC) FILETIME=[DF1100E0:01C4AA22] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Robert, I do understand your concerns, and I also understand why you tried to = get some closure on these issues before leaving. However, I think it is = pretty pointless to ask for consensus right after a messaged = characterized as "I do not at all agree with you but I give up to get = things going again". Thus, I do not think I can agree we have ever had = any consensus "on paper".=20 Right now, I am not at all worried that we will not progress, as we are = really talking to each other and we try to get common understandings. = The problems with the FN work have mainly been a result of non-common = intentions and goals, technology without actual needs being spelled = out, written documentation before mail list consensus, a lack of mail = list discussion, etc. I therefore see the current discussions as something really positive, = we will not get ready by avoiding to discuss and resolve disagreements. /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf = Of > Finking, Robert > Sent: den 4 oktober 2004 16:18 > To: 'rohc@ietf.org' > Subject: RE: [rohc] FN: we're doing it again... >=20 >=20 > Hi L-E, >=20 > ]Lesson to learn: Don't try to judge (enforce) consensus before you=20 > ]actually have it. >=20 > Hmm, OK, point taken - thanks =3D) >=20 > For the record I wasn't trying to judge anything. Although=20 > I'm new to all > this stuff I've quickly picked up that at the IETF it's not=20 > uncommon for old > discussions to get revisited and re-revisited e.g. by=20 > watching Ghyslain and > Zhigang ;-). Since I thought I would have no money this week=20 > to continue > making these posts, I just figured it would be good to check=20 > if there was a > consensus on what Ghyslain said, so that I didn't end up=20 > coming back in a > month's time to find out we hadn't actually made any valid=20 > decisions. Also, > it's worth noting that at the time of posting my below mail,=20 > we did have > consensus on paper. However we seem to have opened it up again, = which, > ironically is what I was trying to avoid. >=20 > ]To me, it seems like today's discussions have actually=20 > brought us closer to >=20 > ]some kind of consensus on these issues, by starting to=20 > understand each=20 > ]other. I might be wrong if you disagree with what has been=20 > said today,=20 > ]just let us know if that is the case. >=20 > I must admit that I don't quite like the new technical=20 > proposals as much as > what we had last week, but I'm not going to barf on them. The thing I > disagree with is carrying on spending time on this=20 > unnecessarily. As you may > recall from my mail I sent out before we started any of this, the = most > important thing to me is to expedite the whole process. We've=20 > been trying > and failing to do that since before Lule=E5, and we're in=20 > danger of continuing > to fail, because we're not focusing on getting this done,=20 > we're focusing on > getting it perfect. >=20 > ] > ]Speaking only for myself, I know that I might sometimes=20 > suggest things that >=20 > ]I will later argue against, if input from others makes me=20 > change my mind.=20 > ]That's what might happen as a result of open discussions. >=20 > That's great! It's nice to know we can be truly objective (a=20 > rare thing) =3D) > But we're miles behind schedule here. The technical issues=20 > are secondary; > they're not show-stoppers. We're spending time on minutiae.=20 > Even with no > changes, the draft as it stands is fine IMHO. Let's just get on with > finishing the TCP profile. I'm sure the FN issues that come=20 > out of that will > dwarf the consideration of whether we use underscores or "import" = type > statements for external encoding methods! >=20 > Anyway too much of a rant again - sorry. The point is that=20 > I'm happy with > pretty much anything as long as we can get a consensus and move on. >=20 > Cheers >=20 > Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 11:44:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15088 for ; Mon, 4 Oct 2004 11:44:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEV9c-0002IZ-LR for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 11:53:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUv5-0004zb-8K; Mon, 04 Oct 2004 11:38:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUse-0004WU-16 for rohc@megatron.ietf.org; Mon, 04 Oct 2004 11:36:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14604 for ; Mon, 4 Oct 2004 11:36:01 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEV1j-0001i1-66 for rohc@ietf.org; Mon, 04 Oct 2004 11:45:28 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 16:36:15 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2140@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Lars-Erik Jonsson (LU/EAB)'" Subject: RE: [rohc] FN: we're doing it again... Date: Mon, 4 Oct 2004 16:36:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable L-E, ]I do understand your concerns, and I also understand why you tried to = get=20 ]some closure on these issues before leaving. However, I think it is = pretty=20 ]pointless to ask for consensus right after a messaged characterized as = "I do=20 ]not at all agree with you but I give up to get things going again". = Thus, I ]do not think I can agree we have ever had any consensus "on paper".=20 Sorry, to clarify: I wasn't trying to get any closure on the issues. I = agree there was not consensus on the issues (which is why they're being = discussed now). However I agreed with Ghyslain, that despite the lack of = consensus on *the issues* we needed to "get things going again". The consensus we = had was that we should settle for Ghyslain's proposals in order to proceed. The problem here is that on the one hand, people replied to my mail saying = they were happy with Ghyslain's proposals, and on the other hand carried on discussing it... because I guess of the not wanting to move on without having technical consensus. ] ]Right now, I am not at all worried that we will not progress, as we = are=20 ]really talking to each other and we try to get common understandings. = The=20 ]problems with the FN work have mainly been a result of non-common intentions=20 ]and goals, technology without actual needs being spelled out, written=20 ]documentation before mail list consensus, a lack of mail list = discussion,=20 ]etc. Though the discussion happened off the list, it still happened - I = don't think using the list would have made any difference. We have the same parties contributing now we're back on the list as we did off the list. = The point of keeping it off the list in the first place, was to prevent us = from polluting the list with stuff that was only of interest to us; at least until we were close to something publishable. Consensus has been reached on several issues, but inevitably at some = later point in time the people who consented are not there, and others are, = and they form a new consensus of their own, despite the previous consensus = that was *published on the list* ] ]I therefore see the current discussions as something really positive, = we=20 ]will not get ready by avoiding to discuss and resolve disagreements. Positive technically yes, just like structures etc. from IETF60, just = like a lot of stuff we came up with at Lule=E5, but not positive from an = expediency point of view. I'm afraid we'll have to disagree about not getting = ready by avoiding discussions! A phrase that I like a lot is "good enough". For = us now, that means a FN which will successfully facilitate the production = of the TCP profile. Anything beyond that is unnecessary. To give a = concrete example, the annotation comment syntax is down in the noise, so for my = money I'd keep it as it is, just so that all the existing examples in the = draft, the existing fragments of TCP profile, Mark's tools and Carsten's tools don't need changing. Still I guess I'm a cheeky newbie who could learn a thing or too. Maybe = I should just keep quiet ;-) Raffles > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf = Of > Finking, Robert > Sent: den 4 oktober 2004 16:18 > To: 'rohc@ietf.org' > Subject: RE: [rohc] FN: we're doing it again... >=20 >=20 > Hi L-E, >=20 > ]Lesson to learn: Don't try to judge (enforce) consensus before you=20 > ]actually have it. >=20 > Hmm, OK, point taken - thanks =3D) >=20 > For the record I wasn't trying to judge anything. Although=20 > I'm new to all > this stuff I've quickly picked up that at the IETF it's not=20 > uncommon for old > discussions to get revisited and re-revisited e.g. by=20 > watching Ghyslain and > Zhigang ;-). Since I thought I would have no money this week=20 > to continue > making these posts, I just figured it would be good to check=20 > if there was a > consensus on what Ghyslain said, so that I didn't end up=20 > coming back in a > month's time to find out we hadn't actually made any valid=20 > decisions. Also, > it's worth noting that at the time of posting my below mail,=20 > we did have > consensus on paper. However we seem to have opened it up again, = which, > ironically is what I was trying to avoid. >=20 > ]To me, it seems like today's discussions have actually=20 > brought us closer to >=20 > ]some kind of consensus on these issues, by starting to=20 > understand each=20 > ]other. I might be wrong if you disagree with what has been=20 > said today,=20 > ]just let us know if that is the case. >=20 > I must admit that I don't quite like the new technical=20 > proposals as much as > what we had last week, but I'm not going to barf on them. The thing I > disagree with is carrying on spending time on this=20 > unnecessarily. As you may > recall from my mail I sent out before we started any of this, the = most > important thing to me is to expedite the whole process. We've=20 > been trying > and failing to do that since before Lule=E5, and we're in=20 > danger of continuing > to fail, because we're not focusing on getting this done,=20 > we're focusing on > getting it perfect. >=20 > ] > ]Speaking only for myself, I know that I might sometimes=20 > suggest things that >=20 > ]I will later argue against, if input from others makes me=20 > change my mind.=20 > ]That's what might happen as a result of open discussions. >=20 > That's great! It's nice to know we can be truly objective (a=20 > rare thing) =3D) > But we're miles behind schedule here. The technical issues=20 > are secondary; > they're not show-stoppers. We're spending time on minutiae.=20 > Even with no > changes, the draft as it stands is fine IMHO. Let's just get on with > finishing the TCP profile. I'm sure the FN issues that come=20 > out of that will > dwarf the consideration of whether we use underscores or "import" = type > statements for external encoding methods! >=20 > Anyway too much of a rant again - sorry. The point is that=20 > I'm happy with > pretty much anything as long as we can get a consensus and move on. >=20 > Cheers >=20 > Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 11:45:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15194 for ; Mon, 4 Oct 2004 11:45:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEVBJ-0002oA-K2 for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 11:55:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUzH-0005LK-Jg; Mon, 04 Oct 2004 11:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEUtV-0004dS-Ax for rohc@megatron.ietf.org; Mon, 04 Oct 2004 11:36:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14631 for ; Mon, 4 Oct 2004 11:36:54 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEV2a-0001io-Sx for rohc@ietf.org; Mon, 04 Oct 2004 11:46:22 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Oct 2004 16:37:16 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2141@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'rohc@ietf.org'" Subject: RE: [rohc] FN: we're doing it again... Date: Mon, 4 Oct 2004 16:37:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "West, Mark" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Carsten: ]> PS yes, I have got more funding this week after all =) ] ]Good! ] ]How's Mark? (And the packet formats?) LOL "Mark and the Packet Formats", sounds like a great name for a band =) I've heard report that would suggest Mark is alive, and possibly even in this country. I've been to look for him today, but didn't actually manage to find him. Did he send you the last version of the packet formats that he's got? If so, you have a more up to date copy than me =) Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 4 17:53:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00561 for ; Mon, 4 Oct 2004 17:53:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEavL-0008Kv-Rn for rohc-web-archive@ietf.org; Mon, 04 Oct 2004 18:03:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEadS-0008Nm-Vp; Mon, 04 Oct 2004 17:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEaRx-00016D-23 for rohc@megatron.ietf.org; Mon, 04 Oct 2004 17:32:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27581 for ; Mon, 4 Oct 2004 17:32:49 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEab6-0004Dz-HC for rohc@ietf.org; Mon, 04 Oct 2004 17:42:21 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i94LWZfF007660; Mon, 4 Oct 2004 23:32:37 +0200 (MEST) In-Reply-To: <41610EF9.6090603@effnet.com> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A212E@rsys004a.roke.co.uk> <41610EF9.6090603@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Mon, 4 Oct 2004 23:32:35 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" , "'Lars-Erik Jonsson \(LU/EAB\)'" , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Oct 04 2004, at 10:51 Uhr, Kristofer Sandlund wrote: > To me, this is a non-valid argument. I've writen a few parsers in my > life, and I cannot see why any parser cannot have one treatment (use > this) for a comment starting with %[ and another one (throw this away) > for a comment that starts with % followed by anything other than [ . That is the easy part. I just implemented the unsavory part: relating back information from an annotation that is written *after* some construct-terminating delimiter. uncompressed_format = protocol; %[16] format_ether_v4 = discriminator, %[ 1 ] next_protocol, %[ 0 ] ... Yech. I need some kimchi to get the bad taste out of my mouth... Gppd night, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 5 03:45:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29705 for ; Tue, 5 Oct 2004 03:45:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEk9k-0002KU-Da for rohc-web-archive@ietf.org; Tue, 05 Oct 2004 03:54:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjyr-0004Pq-CG; Tue, 05 Oct 2004 03:43:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjw6-00041w-Kt for rohc@megatron.ietf.org; Tue, 05 Oct 2004 03:40:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29280 for ; Tue, 5 Oct 2004 03:40:37 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEk5K-0001NX-Ev for rohc@ietf.org; Tue, 05 Oct 2004 03:50:12 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i957eZfM021930 for ; Tue, 5 Oct 2004 09:40:35 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 09:40:35 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4J3L1JRK>; Tue, 5 Oct 2004 09:39:46 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Carsten Bormann'" , Kristofer Sandlund Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update ) Date: Tue, 5 Oct 2004 09:39:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Oct 2004 07:40:35.0444 (UTC) FILETIME=[99CA9B40:01C4AAAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Finking, Robert" , "'rohc@ietf.org'" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 > > To me, this is a non-valid argument. I've writen a few > > parsers in my life, and I cannot see why any parser > > cannot have one treatment (use this) for a comment > > starting with %[ and another one (throw this away) > > for a comment that starts with % followed by anything > > other than [ . > > That is the easy part. > I just implemented the unsavory part: relating back > information from an annotation that is written *after* > some construct-terminating delimiter. > > uncompressed_format = protocol; %[16] > > format_ether_v4 = discriminator, %[ 1 ] > next_protocol, %[ 0 ] > ... > > Yech. I need some kimchi to get the bad taste out of my mouth... But the important thing is not the potential bad taste of implementing a verification tool for protocol development, but that it is doable also with comment-based annotations. This way we can avoid having to modify the notation just for verification purposes in the profile development. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 5 04:51:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04006 for ; Tue, 5 Oct 2004 04:51:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CElBf-0004Gt-CA for rohc-web-archive@ietf.org; Tue, 05 Oct 2004 05:00:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEl1M-0001QY-6U; Tue, 05 Oct 2004 04:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEkzU-00017L-GA for rohc@megatron.ietf.org; Tue, 05 Oct 2004 04:48:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03804 for ; Tue, 5 Oct 2004 04:48:10 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEl8k-0003Kx-AG for rohc@ietf.org; Tue, 05 Oct 2004 04:57:46 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 09:48:21 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A214D@rsys004a.roke.co.uk> From: "Finking, Robert" To: "Finking, Robert" , "'Lars-Erik Jonsson (LU/EAB)'" Date: Tue, 5 Oct 2004 09:48:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "'rohc@ietf.org'" Subject: [rohc] Ooops! (FN: we're doing it again...) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ]Consensus has been reached on several issues, but inevitably at some later ]point in time the people who consented are not there, and others are, and ]they form a new consensus of their own, despite the previous consensus that ]was *published on the list* You know, as I was on my way home last night, it occurred to me, that we never did publish very much at all on the list. Dang! And I did have to go putting those stars in for emphasis too didn't I? =) Let's look in the dictionary: "Positive (noun); wrong at the top of your voice." Now, where's my recipe for humble pie... =) Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 5 07:02:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14697 for ; Tue, 5 Oct 2004 07:02:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEnEY-0005im-Nd for rohc-web-archive@ietf.org; Tue, 05 Oct 2004 07:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEn3n-0006kR-Ni; Tue, 05 Oct 2004 07:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEn2s-0006b6-QA for rohc@megatron.ietf.org; Tue, 05 Oct 2004 06:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14486 for ; Tue, 5 Oct 2004 06:59:48 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEnC9-0005fx-Bs for rohc@ietf.org; Tue, 05 Oct 2004 07:09:26 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i95AxifM026983 for ; Tue, 5 Oct 2004 12:59:48 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 5 Oct 2004 12:59:42 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4J5J4WZL>; Tue, 5 Oct 2004 12:59:43 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Date: Tue, 5 Oct 2004 10:43:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Oct 2004 10:59:42.0677 (UTC) FILETIME=[6AE5B050:01C4AACA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [rohc] Finalizing the FN, proposal for annotations & "underscore" method s X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 FN folks, We've had intensive discussions for a week now, and I think these have been very healthy for getting us to a point where we at least know what we all are talking about and how we envision various pieces in the FN puzzle. It is obvious to me that even when understanding each others arguments, we still do not fully agree. Some of us believe the FN should not at all be influenced by potential/intended use of verification tools in the profile development work, while others think it would just be natural to adapt the FN. Personally, I still have not seen any convincing argument why it would actually be needed to adapt the FN for these verification purposes, and all that we want to do with tools seem to be possible to do also without FN adaptation. I do not care if the tools get "ugly", it is just development tools, while I do care about making the FN simple and clean. Considering last days discussions, I therefore propose the following way forward: 1) Ghyslain updates the FN to make it consistent and clean, incorporating what has been discussed since the last update 2) When it comes to "underscores" as escape character for profile-defined methods, or other ways to clearly refer to methods defined in FN versus in the profile, it is a choice left for profile developers to decide on. For the FN, we should take the text previously suggested by Ghyslain, while in the TCP profile we could e.g. use an approach similar to what Carsten suggested yesterday: "At some point, the TCP draft should have a section that summarizes/lists what methods are defined in English. This section might be phrased like this: ipv4_inferred_dodo === "section 4.7"; udp_inferred_glorp === "section 4.9"; An FN processor could take this as a hint that these methods are defined in English. Look, Ma, no (leading) underscores." 3) Regarding annotations, I strongly believe this is an add-on for verification purposes only, and I am therefore convinced the right place for these is in comments. From yesterdays discussions, it seems like we agree that this approach would work also from a parsing point of view. It thus becomes a profile issue whether and how to use annotations, as Ghyslain wrote yesterday: "I suggested that the ROHC-FN draft removes anything about notation and that we had a note about such annotations being used inside comments into the TCP draft, in the section where we start specifying packet formats." Can we let Ghyslain update the draft according to this, and move on? We will get annotations for the parser, which we define in the TCP profile. We will also make sure in the profile that all methods are clearly referenced, e.g. like suggested by Carsten. Of course we should be able to verify the packet formats, also when there are methods defined in the profile. Objections? Otherwise I suggest that we change focus and start working on the packet formats, a discussion Kristofer re-initiated yesterday. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 5 07:28:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16976 for ; Tue, 5 Oct 2004 07:28:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEneJ-0001as-3r for rohc-web-archive@ietf.org; Tue, 05 Oct 2004 07:38:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEnTx-0001za-F8; Tue, 05 Oct 2004 07:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEnRr-0001bw-3K for rohc@megatron.ietf.org; Tue, 05 Oct 2004 07:25:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16783 for ; Tue, 5 Oct 2004 07:25:38 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEnay-00016g-6t for rohc@ietf.org; Tue, 05 Oct 2004 07:35:14 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i95BPDCA000947; Tue, 5 Oct 2004 13:25:14 +0200 (MEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] Finalizing the FN, proposal for annotations & "underscore" method s Date: Tue, 5 Oct 2004 13:25:13 +0200 To: "Lars-Erik Jonsson (LU/EAB)" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Oct 05 2004, at 10:43 Uhr, Lars-Erik Jonsson (LU/EAB) wrote: > Can we let Ghyslain update the draft according to this, > and move on? Yes, please. I'm really looking forward to crunch the updated packet formats through our tool. We should have a syntactically correct, reasonably up-to-date base set within a couple of hours. I'll put those on the ROHC CVS server. Gruesse, Carsten (PS.: In case my yesterday evening's message was too vitriolic: I was attempting to say that, yes, we do have the in-comment style annotations now in our tool. Unfortunately, I was out of kimchi, so I turned to wasabi covered broad beans.) _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 5 11:07:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06124 for ; Tue, 5 Oct 2004 11:07:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEr4B-0002Oa-70 for rohc-web-archive@ietf.org; Tue, 05 Oct 2004 11:17:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqs0-0005t0-0P; Tue, 05 Oct 2004 11:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqqh-0005eS-MK for rohc@megatron.ietf.org; Tue, 05 Oct 2004 11:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05799 for ; Tue, 5 Oct 2004 11:03:29 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEqzx-0001iA-SV for rohc@ietf.org; Tue, 05 Oct 2004 11:13:09 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i95F3Lli014087; Tue, 5 Oct 2004 17:03:22 +0200 (MEST) In-Reply-To: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Tue, 5 Oct 2004 17:03:20 +0200 To: Carsten Bormann X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" Subject: [rohc] TCP packet formats X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit On Oct 05 2004, at 13:25 Uhr, Carsten Bormann wrote: > We should have a syntactically correct, reasonably up-to-date base set > within a couple of hours. > I'll put those on the ROHC CVS server. They are now at http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/fn/ I expect to update this location frequently with new versions; the CVS functionality also allows to see quickly what has changed. Our semantic checker currently has to say the below about the formats. This is certainly not everything a semantic checker can find, and it may not even all be useful observations, but it will certainly help in finding interesting spots for further examination. Gruesse, Carsten ERROR: Annotation 32 for uncompressed field [item] does not match length 0 in optional32:format_not_present ERROR: Annotation 32 for uncompressed field [item] does not match length 0 in opt_lsb_7_or_31:format_not_present ERROR: Annotation 16 for compressed field [reserved1] does not match length 0 in optional16:format_cs_present ERROR: Annotation 3 for compressed field [version] does not match length 0 in gre:format_gre_static ERROR: Annotation 3 for compressed field [version] does not match length 0 in gre:format_gre_replicate_1 ERROR: Annotation 32 for compressed field [spi] does not match length 0 in esp_null:format_esp_static ERROR: Annotation 6 for uncompressed field [traffic_class] does not match length 8 in ipv6:format_ipv6_replicate ERROR: Annotation 128 for compressed field [dst_addr] does not match length 0 in ipv6:format_ipv6_static ERROR: Annotation 128 for compressed field [dst_addr] does not match length 0 in ipv6:format_ipv6_static_3095 ERROR: Annotation 6 for compressed field [traffic_class] does not match length 8 in ipv6:format_ipv6_replicate ERROR: No uncompressed format for ip_id_behavior_enc! ERROR: Annotation 32 for compressed field [dst_addr] does not match length 0 in ipv4:format_ipv4_static ERROR: Annotation 32 for compressed field [dst_addr] does not match length 0 in ipv4:format_ipv4_static ERROR: Annotation 1 for compressed field [df] does not match length 0 in ipv4:format_ipv4_dynamic ERROR: Annotation 1 for compressed field [ip_id_nbo_flag] does not match length 0 in ipv4:format_ipv4_dynamic ERROR: Annotation 1 for compressed field [df] does not match length 0 in ipv4:format_ipv4_replicate_1 ERROR: Annotation 1 for compressed field [ip_id_nbo_flag] does not match length 0 in ipv4:format_ipv4_replicate_1 ERROR: No uncompressed format for ecn_and_reserved_enc! ERROR: Annotation 16 for compressed field [dst_port] does not match length 0 in tcp:format_tcp_static ERROR: Annotation 1 for compressed field [reserved] does not match length 4 in tcp:format_tcp_dynamic ERROR: No compressed format for tcp_opt_nop! ERROR: No compressed format for tcp_opt_sack_permitted! ERROR: No uncompressed format for list_index! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 02:56:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24645 for ; Wed, 6 Oct 2004 02:56:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF5sc-0002X4-AM for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 03:06:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF5hZ-0006nS-No; Wed, 06 Oct 2004 02:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF5gD-0006YF-Tn for rohc@megatron.ietf.org; Wed, 06 Oct 2004 02:53:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24485 for ; Wed, 6 Oct 2004 02:53:39 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF5pe-0002CJ-Li for rohc@ietf.org; Wed, 06 Oct 2004 03:03:27 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i965qfLh002019 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Oct 2004 07:52:41 +0200 Message-ID: <416396DD.50003@effnet.com> Date: Wed, 06 Oct 2004 08:55:25 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] TCP packet formats References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Hi Carsten and others, As halfway promised, I'm going to _try_ (still no promise due to time constraints) to put together some packet formats before beginning of next week, but the latest version in the CVS is of course a subset of the full packet formats, so I'll have to merge in the packets from tcp-07.txt into this, update them and make some minor modifications to them. So my questions for now are: - Are you ok with the suggested change to remove the "next header iterating scheme" as I proposed earlier this week? I'm a bit relucatant to go into major edits and then find out that the consensus would be that we really would need these things.... Note that with these changes, there is no need to put packet formats for the IR, IR-DYN and IR-CR, since they are defined in the text instead. - ECN. Currently, the ECN uses some form of this "previous" notation, and in line with my proposal to let the user construct the chains I say we add some text about ECN handling in the TCP draft ("when constructing the irregular chain, the user should choose the irregular format postfixed by _ecn if the ECN bits have been set in the context, otherwise the irregular format without _ecn should be chosen. blah blah, better text, but you get my meaning"). This way we get away from another thing that seems unsuitable for the FN to express. - I've only briefly looked at your parser warnings, but some of them seem a bit strange. The first one says that optional32:format_not_present has a annotation of 32, which it does not in the CVS version. Have you updated it since then? BR, Kristofer Sandlund, Effnet AB Carsten Bormann wrote: > > On Oct 05 2004, at 13:25 Uhr, Carsten Bormann wrote: > >> We should have a syntactically correct, reasonably up-to-date base set >> within a couple of hours. >> I'll put those on the ROHC CVS server. > > > They are now at http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/fn/ > I expect to update this location frequently with new versions; the CVS > functionality also allows to see quickly what has changed. > > Our semantic checker currently has to say the below about the formats. > This is certainly not everything a semantic checker can find, and it may > not even all be useful observations, but it will certainly help in > finding interesting spots for further examination. > > Gruesse, Carsten > > ERROR: Annotation 32 for uncompressed field [item] does not match length > 0 in optional32:format_not_present > ERROR: Annotation 32 for uncompressed field [item] does not match length > 0 in opt_lsb_7_or_31:format_not_present > ERROR: Annotation 16 for compressed field [reserved1] does not match > length 0 in optional16:format_cs_present > ERROR: Annotation 3 for compressed field [version] does not match length > 0 in gre:format_gre_static > ERROR: Annotation 3 for compressed field [version] does not match length > 0 in gre:format_gre_replicate_1 > ERROR: Annotation 32 for compressed field [spi] does not match length 0 > in esp_null:format_esp_static > ERROR: Annotation 6 for uncompressed field [traffic_class] does not > match length 8 in ipv6:format_ipv6_replicate > ERROR: Annotation 128 for compressed field [dst_addr] does not match > length 0 in ipv6:format_ipv6_static > ERROR: Annotation 128 for compressed field [dst_addr] does not match > length 0 in ipv6:format_ipv6_static_3095 > ERROR: Annotation 6 for compressed field [traffic_class] does not match > length 8 in ipv6:format_ipv6_replicate > ERROR: No uncompressed format for ip_id_behavior_enc! > ERROR: Annotation 32 for compressed field [dst_addr] does not match > length 0 in ipv4:format_ipv4_static > ERROR: Annotation 32 for compressed field [dst_addr] does not match > length 0 in ipv4:format_ipv4_static > ERROR: Annotation 1 for compressed field [df] does not match length 0 in > ipv4:format_ipv4_dynamic > ERROR: Annotation 1 for compressed field [ip_id_nbo_flag] does not match > length 0 in ipv4:format_ipv4_dynamic > ERROR: Annotation 1 for compressed field [df] does not match length 0 in > ipv4:format_ipv4_replicate_1 > ERROR: Annotation 1 for compressed field [ip_id_nbo_flag] does not match > length 0 in ipv4:format_ipv4_replicate_1 > ERROR: No uncompressed format for ecn_and_reserved_enc! > ERROR: Annotation 16 for compressed field [dst_port] does not match > length 0 in tcp:format_tcp_static > ERROR: Annotation 1 for compressed field [reserved] does not match > length 4 in tcp:format_tcp_dynamic > ERROR: No compressed format for tcp_opt_nop! > ERROR: No compressed format for tcp_opt_sack_permitted! > ERROR: No uncompressed format for list_index! > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 04:03:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29659 for ; Wed, 6 Oct 2004 04:03:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF6v4-00075W-IX for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 04:13:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF6kQ-00085j-Nh; Wed, 06 Oct 2004 04:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF6iY-0007aO-EO for rohc@megatron.ietf.org; Wed, 06 Oct 2004 04:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29438 for ; Wed, 6 Oct 2004 04:00:08 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF6s0-0006tZ-Ah for rohc@ietf.org; Wed, 06 Oct 2004 04:09:56 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i967xxmT018204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 10:00:00 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i967xwV3028584; Wed, 6 Oct 2004 09:59:58 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@informatik.uni-bremen.de using -f To: Kristofer Sandlund Subject: Re: [rohc] TCP packet formats References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> <416396DD.50003@effnet.com> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Wed, 06 Oct 2004 09:59:58 +0200 In-Reply-To: <416396DD.50003@effnet.com> (Kristofer Sandlund's message of "Wed, 06 Oct 2004 08:55:25 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Carsten Bormann , "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Kristofer Sandlund wrote: > - I've only briefly looked at your parser warnings, but some of them > seem a bit strange. The first one says that > optional32:format_not_present has a annotation of 32, which it does > not in the CVS version. No, it says that a field in the *un*compressed format is annotated with 32 which is in conflict with the encoding in optional32:format_not_present: >> ERROR: Annotation 32 for uncompressed field [item] does not match >> length 0 in optional32:format_not_present This means that item in the field order list of uncompressed_format ("uncompressed field [item]") has an annotation of 32, while the encoding for this field in format_not_present binds item:uncomp_length with 0. (Maybe we need to find an easier to understand format for our warnings?) And this is what's in the spec: optional32 (flag) === { uncompressed_format = item; %[ 32 ] [...] format_not_present = item, %[ 0 ] { let (flag:uncomp_value == 0); item ::= value (0, 0); }; }; Here the length attribute for the encoding method should be 32 instead of 0 (and value must be changed to uncompressed_value -- our parser still accepts the old name, too). Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 04:54:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03438 for ; Wed, 6 Oct 2004 04:54:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7iD-0001xU-Gl for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 05:03:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7MD-0006gF-Bp; Wed, 06 Oct 2004 04:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7En-0005M9-VM for rohc@megatron.ietf.org; Wed, 06 Oct 2004 04:33:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01623 for ; Wed, 6 Oct 2004 04:33:27 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7OG-0000Yb-Fy for rohc@ietf.org; Wed, 06 Oct 2004 04:43:16 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i968XHK3006449; Wed, 6 Oct 2004 10:33:18 +0200 (MEST) In-Reply-To: <416396DD.50003@effnet.com> References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> <416396DD.50003@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5F3ABED6-1772-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats Date: Wed, 6 Oct 2004 10:33:17 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit On Oct 06 2004, at 08:55 Uhr, Kristofer Sandlund wrote: > Hi Carsten and others, > > As halfway promised, I'm going to _try_ (still no promise due to time > constraints) to put together some packet formats before beginning of > next week, but the latest version in the CVS is of course a subset of > the full packet formats, so I'll have to merge in the packets from > tcp-07.txt into this, update them and make some minor modifications to > them. > > So my questions for now are: > - Are you ok with the suggested change to remove the "next header > iterating scheme" as I proposed earlier this week? I'm a bit > relucatant to go into major edits and then find out that the consensus > would be that we really would need these things.... Note that with > these changes, there is no need to put packet formats for the IR, > IR-DYN and IR-CR, since they are defined in the text instead. I think this is a reasonable fallback. Of course, I'd prefer to have them in formal notation, as it makes testing the spec much easier, but I don't think we have the time to agree on them (and the FN magic needed) now. > - ECN. Currently, the ECN uses some form of this "previous" notation, > and in line with my proposal to let the user construct the chains I > say we add some text about ECN handling in the TCP draft ("when > constructing the irregular chain, the user should choose the irregular > format postfixed by _ecn if the ECN bits have been set in the context, > otherwise the irregular format without _ecn should be chosen. blah > blah, better text, but you get my meaning"). This way we get away from > another thing that seems unsuitable for the FN to express. We could simply have a special (English-defined) encoding method that succeeds for different parameters depending on some context information about ECN. Similar to (and possbly even formally definable based on) static. > > - I've only briefly looked at your parser warnings, but some of them > seem a bit strange. The first one says that > optional32:format_not_present has a annotation of 32, which it does > not in the CVS version. Have you updated it since then? Well, as Eilert said, actually it does -- the *uncompressed* side is 32 bits, and this does not mesh with the value(0, 0) method. I was confused by the message, too -- we need to fix the text of the message, but the contents is fine. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 04:54:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03519 for ; Wed, 6 Oct 2004 04:54:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7is-0001yc-S2 for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 05:04:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7OW-0006y7-FW; Wed, 06 Oct 2004 04:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7J6-0005ro-Jh for rohc@megatron.ietf.org; Wed, 06 Oct 2004 04:37:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02023 for ; Wed, 6 Oct 2004 04:37:54 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7SX-0000ma-Vl for rohc@ietf.org; Wed, 06 Oct 2004 04:47:43 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i968brWR009735 for ; Wed, 6 Oct 2004 10:37:53 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 10:37:48 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4J5J0K31>; Wed, 6 Oct 2004 10:37:53 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kristofer Sandlund'" Subject: RE: [rohc] TCP packet formats Date: Wed, 6 Oct 2004 10:37:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 06 Oct 2004 08:37:48.0517 (UTC) FILETIME=[C279B950:01C4AB7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > So my questions for now are: > - Are you ok with the suggested change to remove the "next header iterating > scheme" as I proposed earlier this week? I'm a bit relucatant to go into major > edits and then find out that the consensus would be that we really would need > these things.... Note that with these changes, there is no need to put packet > formats for the IR, IR-DYN and IR-CR, since they are defined in the text instead. Yes, I see no reason why we should not manage to get this right with the classic way of defining them, the tricky part that will benefit from using the notation is the compressed formats. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 07:50:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15175 for ; Wed, 6 Oct 2004 07:50:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFATR-0003vT-Nh for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 08:00:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAJO-0007S6-Aw; Wed, 06 Oct 2004 07:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAHJ-00079D-1U for rohc@megatron.ietf.org; Wed, 06 Oct 2004 07:48:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15046 for ; Wed, 6 Oct 2004 07:48:15 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAQl-0003jh-TB for rohc@ietf.org; Wed, 06 Oct 2004 07:58:05 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i96AlFLh003117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Oct 2004 12:47:16 +0200 Message-ID: <4163DBEA.90003@effnet.com> Date: Wed, 06 Oct 2004 13:50:02 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eilert Brinkmann Subject: Re: [rohc] TCP packet formats References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> <416396DD.50003@effnet.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Ok, so now I know what is wrong, but I don't know how I'm supposed to fix this. Mark wrote this structure to indicate that this field will be compressed either as 0 bits or as 32 bits (a variable-length encoding). How should this be written according to the FN? Should I use static instead? /Kristofer Eilert Brinkmann wrote: > Kristofer Sandlund wrote: > >>- I've only briefly looked at your parser warnings, but some of them >>seem a bit strange. The first one says that >>optional32:format_not_present has a annotation of 32, which it does >>not in the CVS version. > > > No, it says that a field in the *un*compressed format is annotated with > 32 which is in conflict with the encoding in optional32:format_not_present: > > >>>ERROR: Annotation 32 for uncompressed field [item] does not match >>>length 0 in optional32:format_not_present > > > This means that item in the field order list of uncompressed_format > ("uncompressed field [item]") has an annotation of 32, while the > encoding for this field in format_not_present binds item:uncomp_length > with 0. (Maybe we need to find an easier to understand format for our > warnings?) And this is what's in the spec: > > optional32 (flag) === { > > uncompressed_format = item; %[ 32 ] > > [...] > > format_not_present = item, %[ 0 ] > { > let (flag:uncomp_value == 0); > > item ::= value (0, 0); > }; > }; > > Here the length attribute for the encoding method should be 32 instead > of 0 (and value must be changed to uncompressed_value -- our parser > still accepts the old name, too). > > Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 08:16:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17388 for ; Wed, 6 Oct 2004 08:16:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAsa-0005h0-Up for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 08:26:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAe1-0002H1-LF; Wed, 06 Oct 2004 08:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAVW-00015W-R7 for rohc@megatron.ietf.org; Wed, 06 Oct 2004 08:02:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16094 for ; Wed, 6 Oct 2004 08:02:57 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAeq-0004fh-T8 for rohc@ietf.org; Wed, 06 Oct 2004 08:12:47 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i96C2RCu020786; Wed, 6 Oct 2004 14:02:29 +0200 (MEST) In-Reply-To: <4163DBEA.90003@effnet.com> References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> <416396DD.50003@effnet.com> <4163DBEA.90003@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97FB6114-178F-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats Date: Wed, 6 Oct 2004 14:02:28 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , Carsten Bormann , "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit On Oct 06 2004, at 13:50 Uhr, Kristofer Sandlund wrote: > Ok, so now I know what is wrong, but I don't know how I'm supposed to > fix this. > Mark wrote this structure to indicate that this field will be > compressed either as 0 bits or as 32 bits (a variable-length > encoding). > How should this be written according to the FN? Should I use static > instead? I think optional32 was meant to either include a value or not, based on a discriminator somewhere (which is given as a parameter). If the flag is off, both the uncompressed and the compressed side are zero-length. If the flag is on, we have an irregular 32-bit field. So what is wrong here is the annotation of the uncompressed_format. If you look at the places where this is used, there is no formal annotation, instead there is a comment saying orig_src, % 0 or 32 bits The same should be true for optional32, i.e.: uncompressed_format = item; % 0 or 32 bits, depending on "flag" This, of course, is a rather boring inconsistency, but it at least identified incorrect documentation of the uncompressed_format of optional32. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 08:18:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17441 for ; Wed, 6 Oct 2004 08:18:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAtZ-0005qQ-JO for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 08:27:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAe3-0002IT-BE; Wed, 06 Oct 2004 08:11:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAWa-0001Ba-V2 for rohc@megatron.ietf.org; Wed, 06 Oct 2004 08:04:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16206 for ; Wed, 6 Oct 2004 08:04:03 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAg4-0004pV-RU for rohc@ietf.org; Wed, 06 Oct 2004 08:13:53 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i96C3rYK021773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 14:03:55 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i96C3rhM029089; Wed, 6 Oct 2004 14:03:53 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: Kristofer Sandlund Subject: Re: [rohc] TCP packet formats References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> <416396DD.50003@effnet.com> <4163DBEA.90003@effnet.com> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Wed, 06 Oct 2004 14:03:53 +0200 In-Reply-To: <4163DBEA.90003@effnet.com> (Kristofer Sandlund's message of "Wed, 06 Oct 2004 13:50:02 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Carsten Bormann , "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Kristofer Sandlund wrote: > Ok, so now I know what is wrong, but I don't know how I'm supposed to fix this. > Mark wrote this structure to indicate that this field will be > compressed either as 0 bits or as 32 bits (a variable-length encoding). > How should this be written according to the FN? Should I use static instead? The only part that's wrong is the encoding for item in format_not_present. The optional32 structure contains three formats: - uncompressed_format (in this item has always 32 bits) - format_present (which I left out with [...] in my previous message; in this format item is encoded as irregular and has always 32 bits) - format_not_present (in which item has always 0 bits on the uncompressed side) After correction the complete structure should look like this: optional32 (flag) === { uncompressed_format = item; %[ 32 ] format_present = item, %[ 32 ] { let (flag:uncomp_value == 1); item ::= irregular (32); }; format_not_present = item, %[ 0 ] { let (flag:uncomp_value == 0); item ::= uncompressed_value (32, 0); }; }; I.e., the only change (aside from using uncompressed_value instead of value) is the first argument of uncompressed_value which was 0 before. Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 08:18:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17476 for ; Wed, 6 Oct 2004 08:18:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAu4-0005r2-Fb for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 08:28:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAeE-0002Rg-SC; Wed, 06 Oct 2004 08:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAc6-0001mq-A7 for rohc@megatron.ietf.org; Wed, 06 Oct 2004 08:09:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16491 for ; Wed, 6 Oct 2004 08:09:44 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAla-0005CB-Pj for rohc@ietf.org; Wed, 06 Oct 2004 08:19:35 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i96C9aQI025435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 14:09:38 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i96C9akx029092; Wed, 6 Oct 2004 14:09:36 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: Carsten Bormann Subject: Re: [rohc] TCP packet formats References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> <416396DD.50003@effnet.com> <4163DBEA.90003@effnet.com> <97FB6114-178F-11D9-BD1D-000A95DC4DB6@tzi.org> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Wed, 06 Oct 2004 14:09:36 +0200 In-Reply-To: <97FB6114-178F-11D9-BD1D-000A95DC4DB6@tzi.org> (Carsten Bormann's message of "Wed, 6 Oct 2004 14:02:28 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "'rohc@ietf.org'" , Kristofer Sandlund , "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Carsten Bormann wrote: > I think optional32 was meant to either include a value or not, based > on a discriminator somewhere (which is given as a parameter). > If the flag is off, both the uncompressed and the compressed side are > zero-length. Sorry, then I was wrong in my prevoius message. My thought was that if the flag is off the uncompressed side should be 32 bits with value 0, but probably that dosn't make sense. Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 08:19:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17601 for ; Wed, 6 Oct 2004 08:19:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAvH-0005sz-N6 for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 08:29:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAeX-0002ZB-AU; Wed, 06 Oct 2004 08:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFAdG-00029G-3F for rohc@megatron.ietf.org; Wed, 06 Oct 2004 08:10:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16772 for ; Wed, 6 Oct 2004 08:10:56 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFAmj-0005EB-Bj for rohc@ietf.org; Wed, 06 Oct 2004 08:20:46 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i96BA0Lh003234 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Oct 2004 13:10:00 +0200 Message-ID: <4163E13F.4090407@effnet.com> Date: Wed, 06 Oct 2004 14:12:47 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] TCP packet formats References: <39818328-16C1-11D9-BD1D-000A95DC4DB6@tzi.org> <416396DD.50003@effnet.com> <4163DBEA.90003@effnet.com> <97FB6114-178F-11D9-BD1D-000A95DC4DB6@tzi.org> In-Reply-To: <97FB6114-178F-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Carsten, Thanks for your clarifications. I'll rewrite the structure using "compressed_value" in the not_present part so that nothing is actually transmitted here. I also change the annotation to being "% 0 or 32" bits in the uncompressed_format optional32 (flag) === { uncompressed_format = item; % 0 or 32 bits format_present = item, %[ 32 ] { let (flag:uncomp_value == 1); item ::= irregular (32); }; format_not_present = item, %[ 0 ] { let (flag:uncomp_value == 0); item ::= compressed_value (0, 0); }; }; Will this satisfy the parser? /Kristofer Carsten Bormann wrote: > > On Oct 06 2004, at 13:50 Uhr, Kristofer Sandlund wrote: > >> Ok, so now I know what is wrong, but I don't know how I'm supposed to >> fix this. >> Mark wrote this structure to indicate that this field will be >> compressed either as 0 bits or as 32 bits (a variable-length encoding). >> How should this be written according to the FN? Should I use static >> instead? > > > I think optional32 was meant to either include a value or not, based on > a discriminator somewhere (which is given as a parameter). > If the flag is off, both the uncompressed and the compressed side are > zero-length. > If the flag is on, we have an irregular 32-bit field. > > So what is wrong here is the annotation of the uncompressed_format. > If you look at the places where this is used, there is no formal > annotation, instead there is a comment saying > > orig_src, % 0 or 32 bits > > The same should be true for optional32, i.e.: > > uncompressed_format = item; % 0 or 32 bits, depending on "flag" > > This, of course, is a rather boring inconsistency, but it at least > identified incorrect documentation of the uncompressed_format of > optional32. > > Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 09:06:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21494 for ; Wed, 6 Oct 2004 09:06:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBeO-0000Yf-Qm for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 09:16:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBNA-0000yE-Mn; Wed, 06 Oct 2004 08:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBKj-0000Fs-JQ for rohc@megatron.ietf.org; Wed, 06 Oct 2004 08:55:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20561 for ; Wed, 6 Oct 2004 08:55:51 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBUE-00084f-10 for rohc@ietf.org; Wed, 06 Oct 2004 09:05:42 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 6 Oct 2004 13:56:07 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2161@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Kristofer Sandlund'" , Carsten Bormann Subject: RE: [rohc] TCP packet formats Date: Wed, 6 Oct 2004 13:55:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Eilert Brinkmann , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 You don't wanna do that ;-) You wanna do this... optional32 (flag) === { uncompressed_format = item; %[ 32 * flag ] format_present = item, %[ 32 ] { let (flag == 1); item ::= irregular (32); }; format_not_present = item, %[ 0 ] { let (flag == 0); item ::= compressed_value (0, 0); }; }; ....or even.... optional32 (flag) === { uncompressed_format = item; %[ 32 * flag ] compressed_format = item, %[ 32 * flag ] { item ::= irregular(32 * flag); }; }; Noting that: 1. "flag" is a parameter, not a field, so it doesn't have any attributes (just an intrinsic value), 2. there is no reason not to use expression syntax within annotations? 3. there is no reason not to use expression syntax to specify the length of the irregular encoding. I'm sure I've missed something here, so let me know =) Raffles -----Original Message----- From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] Sent: Wednesday, October 06, 2004 1:13 PM To: Carsten Bormann Cc: Eilert Brinkmann; 'rohc@ietf.org' Subject: Re: [rohc] TCP packet formats Carsten, Thanks for your clarifications. I'll rewrite the structure using "compressed_value" in the not_present part so that nothing is actually transmitted here. I also change the annotation to being "% 0 or 32" bits in the uncompressed_format optional32 (flag) === { uncompressed_format = item; % 0 or 32 bits format_present = item, %[ 32 ] { let (flag:uncomp_value == 1); item ::= irregular (32); }; format_not_present = item, %[ 0 ] { let (flag:uncomp_value == 0); item ::= compressed_value (0, 0); }; }; Will this satisfy the parser? /Kristofer Carsten Bormann wrote: > > On Oct 06 2004, at 13:50 Uhr, Kristofer Sandlund wrote: > >> Ok, so now I know what is wrong, but I don't know how I'm supposed to >> fix this. >> Mark wrote this structure to indicate that this field will be >> compressed either as 0 bits or as 32 bits (a variable-length encoding). >> How should this be written according to the FN? Should I use static >> instead? > > > I think optional32 was meant to either include a value or not, based on > a discriminator somewhere (which is given as a parameter). > If the flag is off, both the uncompressed and the compressed side are > zero-length. > If the flag is on, we have an irregular 32-bit field. > > So what is wrong here is the annotation of the uncompressed_format. > If you look at the places where this is used, there is no formal > annotation, instead there is a comment saying > > orig_src, % 0 or 32 bits > > The same should be true for optional32, i.e.: > > uncompressed_format = item; % 0 or 32 bits, depending on "flag" > > This, of course, is a rather boring inconsistency, but it at least > identified incorrect documentation of the uncompressed_format of > optional32. > > Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 10:12:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28605 for ; Wed, 6 Oct 2004 10:12:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCfx-0005F8-Vd for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 10:21:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCTv-0000e5-R3; Wed, 06 Oct 2004 10:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCSL-00006i-2j for rohc@megatron.ietf.org; Wed, 06 Oct 2004 10:07:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28179 for ; Wed, 6 Oct 2004 10:07:46 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCbp-0004tk-Fn for rohc@ietf.org; Wed, 06 Oct 2004 10:17:39 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i96E7awm012081; Wed, 6 Oct 2004 16:07:38 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2161@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2161@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8B06B341-17A0-11D9-BD1D-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats Date: Wed, 6 Oct 2004 16:03:47 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Oct 06 2004, at 14:55 Uhr, Finking, Robert wrote: > 2. there is no reason not to use expression syntax within annotations? You have just killed any remaining free time that Eilert may have had :-) > 3. there is no reason not to use expression syntax to specify the > length of > the irregular encoding. Sounds good, but makes building an implementation so much harder. > I'm sure I've missed something here, so let me know =) Well, you created what we call "gratuitous generality". In your second solution, you lost the property that flag can be either 0 or 1. So, for a flag value of 4, you now have a 128 bit field. I do like your first proposal, but Eilert may not :-) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 6 16:36:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08267 for ; Wed, 6 Oct 2004 16:36:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFIgW-0006za-IA for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 16:46:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHmV-0007tM-6b; Wed, 06 Oct 2004 15:48:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHeo-0003ld-No; Wed, 06 Oct 2004 15:41:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27500; Wed, 6 Oct 2004 15:41:00 -0400 (EDT) Message-Id: <200410061941.PAA27500@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 06 Oct 2004 15:41:00 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-context-replication-06.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC):Context Replication for ROHC Profiles Author(s) : G. Pelletier Filename : draft-ietf-rohc-context-replication-06.txt Pages : 19 Date : 2004-10-6 This document defines context replication, a complement to the context initialization procedure found in ROHC (Robust Header Compression) [RFC-3095]. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure, and may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as for example short- lived TCP flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-context-replication-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-context-replication-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-context-replication-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-6152802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-context-replication-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-context-replication-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-6152802.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Wed Oct 6 16:40:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09054 for ; Wed, 6 Oct 2004 16:40:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFIk0-0007OG-RO for rohc-web-archive@ietf.org; Wed, 06 Oct 2004 16:50:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHmX-0007w9-UK; Wed, 06 Oct 2004 15:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHf2-0003oS-3L; Wed, 06 Oct 2004 15:41:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27518; Wed, 6 Oct 2004 15:41:13 -0400 (EDT) Message-Id: <200410061941.PAA27518@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 06 Oct 2004 15:41:13 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-06.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : ROHC Implementer's Guide Author(s) : L. Jonsson, P. Kremer Filename : draft-ietf-rohc-rtp-impl-guide-06.txt Pages : 20 Date : 2004-10-6 This document describes common misinterpretations and some ambiguous points of ROHC [RFC 3095], which defines the framework and four profiles of a robust and efficient header compression scheme. These points have been identified by the members of the ROHC working group during different interoperability test events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-rtp-impl-guide-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-6152808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-6152808.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Thu Oct 7 02:05:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03486 for ; Thu, 7 Oct 2004 02:05:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFRYQ-0002DZ-4K for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 02:15:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFRLs-0001nN-KE; Thu, 07 Oct 2004 02:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFRCX-00077d-Q7 for rohc@megatron.ietf.org; Thu, 07 Oct 2004 01:52:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27578 for ; Thu, 7 Oct 2004 01:52:28 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFRMB-0001PV-CF for rohc@ietf.org; Thu, 07 Oct 2004 02:02:28 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i975qRWR009622 for ; Thu, 7 Oct 2004 07:52:27 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 07:52:26 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4M1TQ2L4>; Thu, 7 Oct 2004 07:52:26 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Date: Thu, 7 Oct 2004 07:52:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 07 Oct 2004 05:52:26.0911 (UTC) FILETIME=[D3268AF0:01C4AC31] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i975qRWR009622 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Subject: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable ROHCers, An implementer sent me questions regarding section 5.4.1.1.2 of RFC 3095, specifically about how to interpret the text on compressor behavior (implementation) for adapting to such optional acks. After discussing with other independent implementers, I think some clarifications are needed to this text.=20 5.4.1.1.2. Optional acknowledgments, upwards transition In addition to NACKs, positive feedback (ACKs) MAY also be used for UOR-2 packets in the Bidirectional Optimistic mode. Upon reception of an ACK for an updating packet, the compressor knows that the decompressor has received the acknowledged packet and the transition to a higher compression state can be carried out immediately. This functionality is optional, so a compressor MUST NOT expect to get such ACKs initially. The compressor MAY use the following algorithm to determine when to expect ACKs for UOR-2 packets. Let an update event be when a sequence of UOR-2 headers are sent to communicate an irregularity in the packet stream. When ACKs have been received for k_3 out of the last n_3 update events, the compressor will expect ACKs. A compressor which expects ACKs will repeat updates (possibly not in every packet) until an ACK is received. A common answer from implementers is "as a decompressor, I never send such acks, and as a compressor I do not look for them or try to change my strategies based on the potential use of them". This approach is of course fine and safe, and even if you want to send the optional acks you will not run into any problems at the decompressor side. However, if an implementer wants to let his compressor adapt to potential use of such acks, as the 3095 text might encourage an=20 implementer to do, the current text is in my opinion not sufficiently detailed on all aspects an implementer must take into account to make this operation safe. There is one conceptual algorithm being described to figure out as a compressor whether UOR-2 acks can be expected, but the text does not explain clearly what to consider when setting values for parameters k_3 and n_3, or the importance of not making over- optimistic assumptions of UOR-2 ack usage. As acks might be sent for other reasons, for example the decompressor might think that he'd like to send over the clock resolution or a loss option, or initiate a mode transfer (which is something that clearly can happen in mid-stream),=20 the compressor must be sure not to interpret that as a signal from the decompressor to always expect UOR-2 acks.=20 I am not saying the 3095 text is actually wrong, but it might encourage an implementer to do "fancy" things, without spelling out all aspects to consider to get a safe implementation. Therefore, I suggest the=20 following (or something along these lines) to be added as a new section=20 in the implementer's guide: 8.12. When to expect UOR-2 ACKs in O-mode Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in O-mode, and explains a conceptual algorithm for a compressor to determine whether such ACKs can be expected from the decompressor, simply using a condition based on unspecified parameters k_3 and n_3. However, what is not clearly pointed out is the importance of being very careful when implementing this confidence algorithm, as using an incorrect expectation on UOR-2 ACKs as a basis for compressor behavior will significantly degrade the compression performance. If a compressor implementation wants to adapt its optimistic approach behavior on potential UOR-2 ACK usage, the confidence algorithm for=20 determining UOR-2 ACK usage must be carefully designed, with k_3=3Dn_3>>1, as UOR-2 ACKs can be sent from a decompressor for other purposes than to actually acknowledge the UOR-2 packet, e.g. to send feedback data such as clock resolution, or to initiate a mode transfer. Before adapting a compressor to the potential use of UOR-2 ACKs, the implementer must ensure all these aspects are considered in the confidence algorithm. It should again be noted that the use of UOR-2 ACKs in O-mode is indeed optional, so a decompressor can send ACKs for other purposes than actually acking the UOR-2, without then having to continue sending them for all UOR-2. Similarly, compressor implementations can totally ignore UOR-2 ACKs for the purpose of adapting the optimistic approach strategies. =20 Comments? /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc. Senior Research Engineer Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 8 404 29 61 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 04:40:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23616 for ; Thu, 7 Oct 2004 04:40:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFTz6-0003Zw-6P for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 04:50:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTdw-0006TA-Fk; Thu, 07 Oct 2004 04:28:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTaP-0005IW-PE for rohc@megatron.ietf.org; Thu, 07 Oct 2004 04:25:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22735 for ; Thu, 7 Oct 2004 04:25:14 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFTk4-0002ea-K2 for rohc@ietf.org; Thu, 07 Oct 2004 04:35:17 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Oct 2004 09:25:33 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2169@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Carsten Bormann'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP packet formats Date: Thu, 7 Oct 2004 09:25:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Eilert Brinkmann , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb ]> 2. there is no reason not to use expression syntax within annotations? ] ]You have just killed any remaining free time that Eilert may have had ]:-) =) ]> 3. there is no reason not to use expression syntax to specify the ]> length of ]> the irregular encoding. ] ]Sounds good, but makes building an implementation so much harder. IIRC this is needed for the TCP profile. Of course we used to have the "expression" encoding method and the "derived_value" encoding method, but they were really cumbersome to use and were both only needed because of the restriction that only constant values could be used as parameters... which itself was only a restriction because it was a limitation imposed by the original Prolog implementation... presumably because it makes the implementation easier to restrict parameters to constant values. Of course, if it turns out that we don't need them for the TCP profile, then all the better for your implementation! ]> I'm sure I've missed something here, so let me know =) ] ]Well, you created what we call "gratuitous generality". ]In your second solution, you lost the property that flag can be either ]0 or 1. ]So, for a flag value of 4, you now have a 128 bit field. Ooops! Good catch. let(flag >= 0 || flag <= 1) Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 04:48:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24098 for ; Thu, 7 Oct 2004 04:48:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFU6e-00047S-Jz for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 04:58:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTrc-0001UL-TD; Thu, 07 Oct 2004 04:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTen-0006sH-6s for rohc@megatron.ietf.org; Thu, 07 Oct 2004 04:29:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23061 for ; Thu, 7 Oct 2004 04:29:46 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFToS-0002zo-7c for rohc@ietf.org; Thu, 07 Oct 2004 04:39:48 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i978Tdnd022584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Oct 2004 10:29:40 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i978TcP7032306; Thu, 7 Oct 2004 10:29:38 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: "Finking, Robert" Subject: Re: [rohc] TCP packet formats References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2169@rsys004a.roke.co.uk> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Thu, 07 Oct 2004 10:29:38 +0200 In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2169@rsys004a.roke.co.uk> (Robert Finking's message of "Thu, 7 Oct 2004 09:25:37 +0100") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "'Carsten Bormann'" , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 "Finking, Robert" wrote: > ]Well, you created what we call "gratuitous generality". > ]In your second solution, you lost the property that flag can be either > ]0 or 1. > ]So, for a flag value of 4, you now have a 128 bit field. > > Ooops! Good catch. > > let(flag >= 0 || flag <= 1) I would suggest let(flag >= 0 && flag <= 1) or let(flag == 0 || flag == 1) instead ;-) Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 04:50:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24233 for ; Thu, 7 Oct 2004 04:50:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFU8P-0004Ht-2d for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 05:00:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTsm-0001ns-Jk; Thu, 07 Oct 2004 04:44:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTim-00083J-RD for rohc@megatron.ietf.org; Thu, 07 Oct 2004 04:33:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23336 for ; Thu, 7 Oct 2004 04:33:54 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFTsR-0003CR-F1 for rohc@ietf.org; Thu, 07 Oct 2004 04:43:56 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Oct 2004 09:34:13 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216A@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Eilert Brinkmann'" Subject: RE: [rohc] TCP packet formats Date: Thu, 7 Oct 2004 09:34:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "'Carsten Bormann'" , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ]"Finking, Robert" wrote: ]> ]Well, you created what we call "gratuitous generality". ]> ]In your second solution, you lost the property that flag can be either ]> ]0 or 1. ]> ]So, for a flag value of 4, you now have a 128 bit field. ]> ]> Ooops! Good catch. ]> ]> let(flag >= 0 || flag <= 1) ] ]I would suggest ] ] let(flag >= 0 && flag <= 1) ] ]or ] ] let(flag == 0 || flag == 1) ] ]instead ;-) LOL. My maths teacher always used to say "Engage brain before opening mouth", perhaps I should go write it out a few hundred times =) Thanks! Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 05:20:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26517 for ; Thu, 7 Oct 2004 05:20:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFUbc-00068V-V3 for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 05:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFUQa-0000fh-NH; Thu, 07 Oct 2004 05:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFUNP-0008O8-A5 for rohc@megatron.ietf.org; Thu, 07 Oct 2004 05:15:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25902 for ; Thu, 7 Oct 2004 05:15:52 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFUX4-0005m1-Uu for rohc@ietf.org; Thu, 07 Oct 2004 05:25:55 -0400 Received: from effnet.com (nat.effnet.com [194.237.235.17]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i978EnLh006709 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Oct 2004 10:14:58 +0200 Message-ID: <4165091C.4030701@effnet.com> Date: Thu, 07 Oct 2004 11:15:08 +0200 From: Kristofer Sandlund User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] TCP packet formats (help me!) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216A@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216A@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , "'Carsten Bormann'" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Hi again. I'm working on another update of the TCP profile packet formats, and there are some things that I don't know how to resolve with ROHC-FN. Since it's the first time I'm actually trying to write something in FN instead of just dumping on what others have done, I really need some help from the experts (hint: if you're CC:ed to this mail....) Issue 1: ********************* In Mark's latest version of the formats, there is tcpip_co === { uncompressed_format = src_port, %[ 16 ] dst_port, %[ 16 ] rsf_flags, %[ 3 ] psh_flag, %[ 1 ] urg_flag, %[ 1 ] ack_flag, %[ 1 ] offset, %[ 4 ] ecn_flags, %[ 2 ] res_flags, %[ 4 ] urg_ptr, %[ 16 ] window, %[ 16 ] checksum, %[ 16 ] seq_number, %[ 32 ] ack_number, %[ 32 ] options; % n bits .... Since the CO packet formats are "base headers" and are a compressed preresentation for both the TCP header AND the innermost IP header, the uncompressed format should really be one (IPv4 or IPv6) and one TCP header. Therefore, I've added something like: ip_hdr === { uncompressed_format = inner_ip; format_inner_v4 = ipv4, { inner_ip ::= ipv4; } format_inner_v6 = ipv6, { inner_ip ::= ipv6; } }; tcpip_co === { uncompressed format = ip_hdr, % 160 or 320 bits tcp; % 160 + n bits .... Is this possible with FN? If not, any suggestions how to solve this? (yes, laughing is allowed here) Issue 2: ************************* default_methods for the tcpip_co. Mark just listed all fields from IPv4 and TCP here, but in line with issue 1, this is not really correct. It is clearly "enough" information, but how do I express that IPv4 TOS equals IPv6 TC and the same for TTL/HOPLIMIT? Also, do I need to make some provisions for fields that only appear in one of the IP headers such as DF, MF? Issue 3: ********************** List encoding. (once again, this mammoth rises up and bites us all in the ass). I must admit that I thought the latest FN (Robert's text) had cleared this up, but now I don't really see how to use it. For TCP options, I will define a structure tcp_options, but HOW should I write this (Robert, this is aimed at you)?. I read the examples in FN, but hit a brick wall. What I would have liked would be to have a structure that creates both "list header", "xi_list" and "item_list" instead of having to do each of these separately in each profile using list encoding. Please provide me with sample FN for this, 'cause I got about this far: tcp_options === { list_header; xi_list; item_list; }; Which of course is just BS. I'll probably get back with more things as soon as I try to fix NBO for the IPIDs but that's a whole new story. BR, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 06:29:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01462 for ; Thu, 7 Oct 2004 06:29:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVgE-0001cf-Of for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 06:39:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVVJ-00074z-Q0; Thu, 07 Oct 2004 06:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVQP-0006LX-Cz for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:23:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00983 for ; Thu, 7 Oct 2004 06:23:02 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVa5-00017c-Ga for rohc@ietf.org; Thu, 07 Oct 2004 06:33:06 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <4J954KZD>; Thu, 7 Oct 2004 11:23:27 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Kristofer Sandlund'" Subject: RE: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 11:23:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: "'Eilert Brinkmann'" , "'Carsten Bormann'" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 ]Since the CO packet formats are "base headers" and are a compressed ]preresentation for both the TCP header AND the innermost IP header, the ]uncompressed format should really be one (IPv4 or IPv6) and one TCP header. ]Therefore, I've added something like: ] ]ip_hdr === { ] uncompressed_format = inner_ip; ] ] format_inner_v4 = ipv4, ] { ] inner_ip ::= ipv4; ] } ] ] format_inner_v6 = ipv6, ] { ] inner_ip ::= ipv6; ] } ] ]}; ] ]tcpip_co === { ] ] uncompressed format = ip_hdr, % 160 or 320 bits ] tcp; % 160 + n bits ] ].... ] ]Is this possible with FN? If not, any suggestions how to solve this? Yes, that's totally fine - it is intended to be used in just that fashion. The only restriction on doing that is that both the compressor and the decompressor must be able to disambiguate the two options. The compressor must be able to distinguish between the two, since they have two different semantics; the decompressor for the usual reason! It must always be possible to do this at the compressor end, otherwise you have an ill defined problem - it's just a case of notating it correctly. At the decompressor end, it's dependent on whether the compressed formats have intrinsically any distinguishing features which make it possible to tell them apart. If it's not possible, then you need to add an explicit discriminator, to differentiate between the two compressed formats. Does that answer your question, or did I just confuse things more? ]Issue 2: ]************************* ]default_methods for the tcpip_co. Mark just listed all fields from IPv4 ]and TCP here, but in line with issue 1, this is not really correct. ]It is clearly "enough" information, but how do I express that IPv4 TOS ]equals IPv6 TC and the same for TTL/HOPLIMIT? I think the answer is you need to give the fields the same name. So instead of calling it tc in IPv6 and tos in IPv4, call it tos_tc or some similar in both. ]Also, do I need to make some provisions for fields that only appear in ]one of the IP headers such as DF, MF? Ag, I don't have enough knowledge of the protocols do know what DF and MF are, so I'm not quite sure what you're asking. Could you explain what it is you want in simple terms - preferably slowly, maybe using examples that only involve sandwiches ;-) ]Issue 3: ]********************** ]List encoding. (once again, this mammoth rises up and bites us all in ]the ass). ]I must admit that I thought the latest FN (Robert's text) had cleared ]this up, but now I don't really see how to use it. ]For TCP options, I will define a structure tcp_options, but HOW should I ]write this (Robert, this is aimed at you)?. I read the examples in FN, ]but hit a brick wall. What I would have liked would be to have a ]structure that creates both "list header", "xi_list" and "item_list" ]instead of having to do each of these separately in each profile using ]list encoding. ] ]Please provide me with sample FN for this, 'cause I got about this far: ]tcp_options === ]{ ] list_header; ] xi_list; ] item_list; ]}; ]Which of course is just BS. =) The notation does create the "list header", "xi_list" and "item_list" instead of having to do each of these separately. First off, note that all identifiers for lists start with "list" - this the unique bit of syntax that defines this as a list, rather than a regular structure (unless anybody has a better idea). The second thing, is you have to have a length parameter, which has the fixed name "list_length_in_bytes". All you then need to do is include the encodings for each of the possible items in the list (including the special cases of the terminating item and subsequent padding). To quote the example in the FN draft: list_tcp_options(list_length_in_bytes) === { end_of_list_sentinel ::= uncompressed_value(8, 0); end_of_list_pad ::= uncompressed_value(8, 1); : : timestamp ::= tcp_timestamp_list_item(); : : : : etc. }; tcp_timestamp_list_item() === { uncompressed_format = type, length, timestamp_value, timestamp_echo_reply; default_methods = { type ::= uncompressed_value(8, 8); length ::= uncompressed_value(8, 10); }; compressed_format_first = timestamp_value, timestamp_echo_reply { let (this:has_context == false); timestamp_value ::= irregular(32); timestamp_echo_reply ::= irregular(32); }; compressed_format_subsequent = timestamp_value, timestamp_echo_reply { let (this:has_context == true); timestamp_value ::= lsb(16, 0); timestamp_echo_reply ::= lsb(16, 0); }; }; Note the use of the has_context attribute, and the fact that the "with context" encoding doesn't have to be static, and that the "without context" encoding doesn't have to be irregular. I hope this helps! Please feel free to ask more questions - I'm quite pleased with the list notation =) Cheers Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 06:32:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01615 for ; Thu, 7 Oct 2004 06:32:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVjC-0001nv-Ft for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 06:42:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVWJ-0007KA-A1; Thu, 07 Oct 2004 06:29:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVV6-0006vc-SA for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:27:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01435 for ; Thu, 7 Oct 2004 06:27:53 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVed-0001TI-Bl for rohc@ietf.org; Thu, 07 Oct 2004 06:37:57 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i97ARZLX015518; Thu, 7 Oct 2004 12:27:37 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <817916C0-184B-11D9-BE81-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 12:27:35 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Oct 07 2004, at 12:23 Uhr, Finking, Robert wrote: > The compressor must be able to distinguish between the two, since they > have two different semantics; the decompressor for the usual reason! > It must always be possible to do this at the compressor end, otherwise > you have an ill defined problem My view is that it's perfectly legal to have ambiguous compression -- obviously, you can always send an IR but there may be one or more other matches. It is a quality of implementation issue, not an issue that needs to be covered in the FN specification, to select a match that results in the smallest number of bits (for this and, likely, for the following packets). The decompressor, on the other hand, is better not requested to solve a riddle. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 06:56:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03431 for ; Thu, 7 Oct 2004 06:56:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFW6Z-0003GR-Od for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVhC-0000vy-OF; Thu, 07 Oct 2004 06:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVaw-0008Io-N2 for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:33:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01741 for ; Thu, 7 Oct 2004 06:33:55 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVkd-0001p8-82 for rohc@ietf.org; Thu, 07 Oct 2004 06:43:59 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i97AXmOu019273; Thu, 7 Oct 2004 12:33:49 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6069EFFD-184C-11D9-BE81-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 12:33:49 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Oct 07 2004, at 12:23 Uhr, Finking, Robert wrote: > Also, do I need to make some provisions for fields that only appear in > ]one of the IP headers such as DF, MF? > > Ag, I don't have enough knowledge of the protocols do know what DF and > MF are, so I'm not quite sure what you're asking. Could you explain > what it is you want in simple terms - preferably slowly, maybe using > examples that only involve sandwiches ;-) A field like MF that always has a specific value in the packets we want to compress is expressed by mf ::= uncompressed_value(1, 0); DF is more interesting -- an IPv6 packet feels like an IPv4 packet for which DF has been set. One way to reflect this in the FN is to have a field that is seen neither on the compressed nor on the uncompressed side: uncompressed_format ::= a, b, c; compressed_format_1 ::= a, b, c { a ::= ...; b ::= ...; c ::= ...; df ::= uncompressed_value(1, 1); } This is, of course, only useful if some other part of the spec is looking for a DF field. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 06:57:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03502 for ; Thu, 7 Oct 2004 06:57:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFW7P-0003Hb-2p for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:07:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVvR-0003EK-Tj; Thu, 07 Oct 2004 06:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVcF-0000CC-Jo for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:35:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01869 for ; Thu, 7 Oct 2004 06:35:16 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVlv-0001uP-W9 for rohc@ietf.org; Thu, 07 Oct 2004 06:45:20 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i97AZ8fL021378; Thu, 7 Oct 2004 12:35:10 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <903C1725-184C-11D9-BE81-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 12:35:10 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Oct 07 2004, at 12:23 Uhr, Finking, Robert wrote: > list_tcp_options(list_length_in_bytes) === > { > end_of_list_sentinel ::= uncompressed_value(8, 0); > end_of_list_pad ::= uncompressed_value(8, 1); > : : > timestamp ::= tcp_timestamp_list_item(); > : : > : : > etc. > }; Can't parse this. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 06:59:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03714 for ; Thu, 7 Oct 2004 06:59:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFW9D-0003Sh-CK for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:09:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVvS-0003Ey-C7; Thu, 07 Oct 2004 06:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVcc-0000CJ-4z for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01900 for ; Thu, 7 Oct 2004 06:35:39 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVmH-0001qQ-PQ for rohc@ietf.org; Thu, 07 Oct 2004 06:45:43 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Oct 2004 11:35:58 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216E@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 11:36:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "'Eilert Brinkmann'" , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ]On Oct 07 2004, at 12:23 Uhr, Finking, Robert wrote: ] ]> The compressor must be able to distinguish between the two, since they ]> have two different semantics; the decompressor for the usual reason! ]> It must always be possible to do this at the compressor end, otherwise ]> you have an ill defined problem ] ]My view is that it's perfectly legal to have ambiguous compression -- ]obviously, you can always send an IR but there may be one or more other ]matches. ]It is a quality of implementation issue, not an issue that needs to be ]covered in the FN specification, to select a match that results in the ]smallest number of bits (for this and, likely, for the following ]packets). ] ]The decompressor, on the other hand, is better not requested to solve a ]riddle. Yes, for the case where you are specifying two or more ways of compressing a *single uncompressed* format I agree totally with this. I was talking here about distinguishing between *multiple uncompressed* formats. E.g. if you had two versions of a protocol whose only distinguishing feature was the version number, and you notated that version number as being irregular, the compressor wouldn't be able to tell the difference between them. Does that make sense? Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 07:02:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04022 for ; Thu, 7 Oct 2004 07:02:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFWCB-0003em-UA for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:12:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVxM-0003oB-Lx; Thu, 07 Oct 2004 06:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFViC-00014O-8W for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02234 for ; Thu, 7 Oct 2004 06:41:25 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVrs-00025W-0b for rohc@ietf.org; Thu, 07 Oct 2004 06:51:29 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Oct 2004 11:41:43 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216F@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 11:41:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "'Eilert Brinkmann'" , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ]> list_tcp_options(list_length_in_bytes) === ]> { ]> end_of_list_sentinel ::= uncompressed_value(8, 0); ]> end_of_list_pad ::= uncompressed_value(8, 1); ]> : : ]> timestamp ::= tcp_timestamp_list_item(); ]> : : ]> : : ]> etc. ]> }; ] ]Can't parse this. Go on, then, give us a clue! What line is causing you a problem ? Is it a silly, or is there a more fundamental flaw here? Cheers Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 07:03:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04078 for ; Thu, 7 Oct 2004 07:03:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFWDK-0003fr-NC for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:13:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVxO-0003p1-3B; Thu, 07 Oct 2004 06:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVic-00015D-Pj for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:41:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02407 for ; Thu, 7 Oct 2004 06:41:51 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVsJ-0002F1-AU for rohc@ietf.org; Thu, 07 Oct 2004 06:51:55 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i97AfimV024582; Thu, 7 Oct 2004 12:41:45 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216E@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216E@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C11707E-184D-11D9-BE81-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 12:41:45 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit On Oct 07 2004, at 12:36 Uhr, Finking, Robert wrote: > Yes, for the case where you are specifying two or more ways of > compressing a > *single uncompressed* format I agree totally with this. > > I was talking here about distinguishing between *multiple uncompressed* > formats. E.g. if you had two versions of a protocol whose only > distinguishing feature was the version number, and you notated that > version > number as being irregular, the compressor wouldn't be able to tell the > difference between them. > > Does that make sense? Yes, that makes a lot of sense. There may be other reasons why this is disambiguated. Even if it is not, there is no conceptual difference between this and multiple compressed formats. You can always transform: foo === { uncompressed_format_1 = a, b; uncompressed_format_2 = b, a; compressed_format = a, b { a ::= ...; b ::= ...; } } into foo === { uncompressed_format = bar; compressed_format_1 = bar { bar ::= foo1; }; compressed_format_2 = bar { bar ::= foo2; } } foo1 === { uncompressed_format = a, b; compressed_format = a, b { a ::= ...; b ::= ...; } } foo2 === { uncompressed_format = b, a; compressed_format = a, b { a ::= ...; b ::= ...; } } It just happens to be much longer. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 07:04:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04123 for ; Thu, 7 Oct 2004 07:04:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFWEC-0003gq-OQ for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:14:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVxO-0003p8-DA; Thu, 07 Oct 2004 06:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVkR-0001Mq-1c for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:43:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02537 for ; Thu, 7 Oct 2004 06:43:43 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVu7-0002Fv-Ea for rohc@ietf.org; Thu, 07 Oct 2004 06:53:48 -0400 Received: from effnet.com (nat.effnet.com [194.237.235.17]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i979gnLh006950 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Oct 2004 11:42:50 +0200 Message-ID: <41651DBC.6030309@effnet.com> Date: Thu, 07 Oct 2004 12:43:08 +0200 From: Kristofer Sandlund User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] TCP packet formats (help me!) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216D@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , "'Carsten Bormann'" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hi Raffles and thanks for the explanations. Comments inlined. Finking, Robert wrote: > ]Since the CO packet formats are "base headers" and are a compressed > ]preresentation for both the TCP header AND the innermost IP header, the > ]uncompressed format should really be one (IPv4 or IPv6) and one TCP header. > ]Therefore, I've added something like: > ] > ]ip_hdr === { > ] uncompressed_format = inner_ip; > ] > ] format_inner_v4 = ipv4, > ] { > ] inner_ip ::= ipv4; > ] } > ] > ] format_inner_v6 = ipv6, > ] { > ] inner_ip ::= ipv6; > ] } > ] > ]}; > ] > ]tcpip_co === { > ] > ] uncompressed format = ip_hdr, % 160 or 320 bits > ] tcp; % 160 + n bits > ] > ].... > ] > ]Is this possible with FN? If not, any suggestions how to solve this? > > Yes, that's totally fine - it is intended to be used in just that fashion. The only restriction on doing that is that both the compressor and the decompressor must be able to disambiguate the two options. The compressor must be able to distinguish between the two, since they have two different semantics; the decompressor for the usual reason! It must always be possible to do this at the compressor end, otherwise you have an ill defined problem - it's just a case of notating it correctly. At the decompressor end, it's dependent on whether the compressed formats have intrinsically any distinguishing features which make it possible to tell them apart. If it's not possible, then you need to add an explicit discriminator, to differentiate between the two compressed formats. Does that answer your question, or did I just confuse things more? Wow. I actually managed som FN! Now, how to make this work on the decompressor side; then I will have to open up a can of worms that I just managed to close (the chain stuff). To say if the innermost is v4 or v6, the decompressor must inspect the static chain previouly received (the version field of this one), so I guess I'd in that case have to provide a version argument to this structure, but where to I get that one from? I need to think more about this obviously. Good ideas appreciated as usual. > > ]Issue 2: > ]************************* > ]default_methods for the tcpip_co. Mark just listed all fields from IPv4 > ]and TCP here, but in line with issue 1, this is not really correct. > ]It is clearly "enough" information, but how do I express that IPv4 TOS > ]equals IPv6 TC and the same for TTL/HOPLIMIT? > > I think the answer is you need to give the fields the same name. So instead of calling it tc in IPv6 and tos in IPv4, call it tos_tc or some similar in both. Ok, that's a good idea. I'll try that. > > ]Also, do I need to make some provisions for fields that only appear in > ]one of the IP headers such as DF, MF? > > Ag, I don't have enough knowledge of the protocols do know what DF and MF are, so I'm not quite sure what you're asking. Could you explain what it is you want in simple terms - preferably slowly, maybe using examples that only involve sandwiches ;-) So for example, the DF bit is "Don't fragment" in IPv4 and no equivalent exists in the IPv6 header, so the IPv6 would ALWAYS set this field to zero in the compressed packet, while nothing ends up in the uncompressed header. For IPv4, the fields can take on different values in the compressed and uncompressed headers. Should I set some control field for those in the v6 part so that they always exist? (if sandwiches are needed in the example, the DF bit would be like you have to swallow the sandwich whole and not chew it) > > ]Issue 3: > ]********************** > ]List encoding. This will require a bit more thinking, so I'll get back on that later. BR, Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 07:07:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04344 for ; Thu, 7 Oct 2004 07:07:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFWGn-0003si-O7 for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:17:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVxX-0003xk-PQ; Thu, 07 Oct 2004 06:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFVlf-0001Xu-Pc for rohc@megatron.ietf.org; Thu, 07 Oct 2004 06:45:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02587 for ; Thu, 7 Oct 2004 06:45:00 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVvL-0002WN-Dq for rohc@ietf.org; Thu, 07 Oct 2004 06:55:04 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i97Aiqcd026267; Thu, 7 Oct 2004 12:44:53 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216F@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A216F@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 12:44:53 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Oct 07 2004, at 12:41 Uhr, Finking, Robert wrote: > ]> list_tcp_options(list_length_in_bytes) === > ]> { > ]> end_of_list_sentinel ::= uncompressed_value(8, 0); > ]> end_of_list_pad ::= uncompressed_value(8, 1); > ]> : : > ]> timestamp ::= tcp_timestamp_list_item(); > ]> : : > ]> : : > ]> etc. > ]> }; > ] > ]Can't parse this. > > Go on, then, give us a clue! What line is causing you a problem ? Is > it a > silly, or is there a more fundamental flaw here? I don't see uncompressed_formats and compressed_formats. These are required in a structure. I.e., you can only have ::= in a compressed_format (or the default_methods, which fills in the compressed_formats). Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 07:27:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05581 for ; Thu, 7 Oct 2004 07:27:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFWae-00054M-D0 for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 07:37:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFWIo-0000vP-Gd; Thu, 07 Oct 2004 07:19:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFWCA-0007tK-C6 for rohc@megatron.ietf.org; Thu, 07 Oct 2004 07:12:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04667 for ; Thu, 7 Oct 2004 07:12:23 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFWLr-0004F9-7u for rohc@ietf.org; Thu, 07 Oct 2004 07:22:27 -0400 Received: from effnet.com (nat.effnet.com [194.237.235.17]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i97ABTLh007063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Oct 2004 12:11:30 +0200 Message-ID: <41652473.4050505@effnet.com> Date: Thu, 07 Oct 2004 13:11:47 +0200 From: Kristofer Sandlund User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'rohc@ietf.org'" , Carsten Bormann , "Finking, Robert" , "'West, Mark'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [rohc] TCP packet formats - IP ID X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Next issue: IPID behavior. Normally, I'd need Mark to answer this since it is his packet formats that I'm updating, but since he's disappeared into /dev/null or some other nasty place, the rest of you have to do. In format_ipv4_dynamic we have: ip_id_behavior, %[ 2 ] ip_id_nbo_flag, %[ 1 ] And the following text % % compressor chooses behavior of IP-ID % 00 = sequential % 01 = sequential [MUST NOT BE USED!] % 10 = random % 11 = zero As I see it, we can only have 4 different types of behavior: Sequential, Sequential-byteswapped, Random and Zero, so I cannot see why we'd need three bits for this. The "MUST NOT BE USED" comment seems like it is there for a good reason, but I can't find that reason. If no one can enlighten me, I think I'll try to change 01 to seq-byteswapped instead. /Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 10:01:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17078 for ; Thu, 7 Oct 2004 10:01:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYzZ-0006b6-Gz for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 10:11:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYp4-0000ri-0w; Thu, 07 Oct 2004 10:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYXt-0005xb-LT for rohc@megatron.ietf.org; Thu, 07 Oct 2004 09:43:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16091 for ; Thu, 7 Oct 2004 09:42:59 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYhb-0005Ur-Iw for rohc@ietf.org; Thu, 07 Oct 2004 09:53:04 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <4J954LBV>; Thu, 7 Oct 2004 14:43:18 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2175@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Carsten Bormann'" Subject: RE: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 14:43:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "'Eilert Brinkmann'" , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 ]> ]> list_tcp_options(list_length_in_bytes) === ]> ]> { ]> ]> end_of_list_sentinel ::= uncompressed_value(8, 0); ]> ]> end_of_list_pad ::= uncompressed_value(8, 1); ]> ]> : : ]> ]> timestamp ::= tcp_timestamp_list_item(); ]> ]> : : ]> ]> : : ]> ]> etc. ]> ]> }; ]> ] ]> ]Can't parse this. ]> ]> Go on, then, give us a clue! What line is causing you a problem ? Is ]> it a ]> silly, or is there a more fundamental flaw here? ] ]I don't see uncompressed_formats and compressed_formats. These are ]required in a structure. That's true, but this isn't a structure, it's a list structure, which has different syntax. The syntax for lists is simpler than for ordinary structures - there is no mapping between compressed and uncompressed to specify in the list syntax itself - you do that in the encoding methods for each of the possible list items. All that the list syntax specifies is: 1. what items can occur in the list, 2. how to encode them 3. how the list is terminated (including any padding if needed) I'm wondering if people have actually read the sections on list encoding yet? If so, it obviously needs clarifying - I'd thought I'd spelt all this out =) Cheers Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 7 13:05:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05216 for ; Thu, 7 Oct 2004 13:05:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbrG-0001jf-Ev for rohc-web-archive@ietf.org; Thu, 07 Oct 2004 13:15:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbaj-0000sj-K2; Thu, 07 Oct 2004 12:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbZW-0000LM-UM for rohc@megatron.ietf.org; Thu, 07 Oct 2004 12:56:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04426 for ; Thu, 7 Oct 2004 12:56:51 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbj6-0001DD-Ta for rohc@ietf.org; Thu, 07 Oct 2004 13:06:59 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i97GuMlS012507; Thu, 7 Oct 2004 18:56:23 +0200 (MEST) In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2175@rsys004a.roke.co.uk> References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2175@rsys004a.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] TCP packet formats (help me!) Date: Thu, 7 Oct 2004 18:56:23 +0200 To: "Finking, Robert" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , Carsten Bormann , "'rohc@ietf.org'" , "'Kristofer Sandlund'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit On Oct 07 2004, at 15:43 Uhr, Finking, Robert wrote: > That's true, but this isn't a structure, it's a list structure, which > has different syntax. I'm sorry, I haven't read 4.10 yet, as this was never discussed, and I though we didn't need it. We will do this tomorrow. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 8 02:49:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28438 for ; Fri, 8 Oct 2004 02:49:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFoio-0007oe-7B for rohc-web-archive@ietf.org; Fri, 08 Oct 2004 02:59:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFoVl-0001rc-S3; Fri, 08 Oct 2004 02:45:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFoQp-0001Gq-BX for rohc@megatron.ietf.org; Fri, 08 Oct 2004 02:40:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27985 for ; Fri, 8 Oct 2004 02:40:45 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFoaf-0007f7-7H for rohc@ietf.org; Fri, 08 Oct 2004 02:50:58 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i985dgLh010123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Oct 2004 07:39:49 +0200 Message-ID: <416636F2.4070403@effnet.com> Date: Fri, 08 Oct 2004 08:42:58 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] TCP packet formats (help me!) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2175@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2175@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: "'Eilert Brinkmann'" , "'Carsten Bormann'" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Ok, now I have a bit better understanding of how to use the list encoding in the FN, but it seems to be a bit out of synch with what we've said in tcp-07. In the definition of the packet formats for ROHC-TCP, the most frequent type of TCP options are described. Each of these options has an uncompressed format, a list_item format and an irregular format. So our definitions of each TCP option is assumed to be a structure that contains both irregular chain item and list item, while your definition puts the list_items into its own structure and it seems to require both a "first" and a "subsequent" format. Or do you mean the subsequent to be the irregular chain item? A list item will either be present (_list_item) or else it is not a part of a list structure at all, it is then part of the irregular chain (see tcp-07 sections 4.6 and 6.6.5). Therefore I'm not too sure about the need of a "has_context" attribute, can't we just leave this to the implementation to decide if it should be in list or if it should be in the irregular chain? Another thing is that in -07, we use the EOL item to end the list, but it is defined to also contain the padding, so I assume I don't have to define a sentinel/pad and solely rely on the length parameter here? /Kristofer Finking, Robert wrote: > ]> ]> list_tcp_options(list_length_in_bytes) === > ]> ]> { > ]> ]> end_of_list_sentinel ::= uncompressed_value(8, 0); > ]> ]> end_of_list_pad ::= uncompressed_value(8, 1); > ]> ]> : : > ]> ]> timestamp ::= tcp_timestamp_list_item(); > ]> ]> : : > ]> ]> : : > ]> ]> etc. > ]> ]> }; > ]> ] > ]> ]Can't parse this. > ]> > ]> Go on, then, give us a clue! What line is causing you a problem ? Is > ]> it a > ]> silly, or is there a more fundamental flaw here? > ] > ]I don't see uncompressed_formats and compressed_formats. These are > ]required in a structure. > > That's true, but this isn't a structure, it's a list structure, which has different syntax. > > The syntax for lists is simpler than for ordinary structures - there is no mapping between compressed and uncompressed to specify in the list syntax itself - you do that in the encoding methods for each of the possible list items. All that the list syntax specifies is: > 1. what items can occur in the list, > 2. how to encode them > 3. how the list is terminated (including any padding if needed) > > I'm wondering if people have actually read the sections on list encoding yet? If so, it obviously needs clarifying - I'd thought I'd spelt all this out =) > > Cheers > > Raffles > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 8 05:30:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07390 for ; Fri, 8 Oct 2004 05:30:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFrFA-0002Jn-GN for rohc-web-archive@ietf.org; Fri, 08 Oct 2004 05:40:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFr3V-00054J-M7; Fri, 08 Oct 2004 05:28:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFr1y-0004rH-0Z for rohc@megatron.ietf.org; Fri, 08 Oct 2004 05:27:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07253 for ; Fri, 8 Oct 2004 05:27:15 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFrBq-0002GX-6C for rohc@ietf.org; Fri, 08 Oct 2004 05:37:30 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i988QJLh010598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 8 Oct 2004 10:26:20 +0200 Message-ID: <41665E01.10009@effnet.com> Date: Fri, 08 Oct 2004 11:29:37 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: [rohc] Content of TCP packet formats X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit In parallell with discussing how to notate these, I figured I'd try to get some input of their actual content even though this has proven to be a near-impossible task in the past. So, reviewing Mark's latest packet formats I've summarized them as follows: Common (1 packet) - (swiss army knife, can transmit basically any dynamic field) Seq-IPID (17 packets) (sequential and sequential-byteswapped) Random-IPID (12 packets) - Random, none or zero IPID List of the number of times each field appears in the CO packets (variable number of bits for some fields): Note that all packets WILL contain discriminator, crc, push bit and msn Sequential packets: ---- IP-ID: ALL Sequence number - ALL ECN behavior - 6 (too many, I sugggest only the common packet can change the behavior. All can still transmit ecn if on or off. Keeping 2 is ok I guess if crc is 7 bit, but a 3-bit CRC for something that changes the irregular chain seems weak) ACK number - 8 packets Hoplimit/TTL - 6 packets (too much, I suggest a reduction to max 2 packets, and maybe these should have a 7-bit CRC) TOS/TC (not including ECN bits)- 5 packets (a bit too much, I suggest reduction to 2 or 3 (w/ crc-7) or even down to 0 and let common handle this) window size: 4 (ok? actually I don't know) Random packets: ---- Sequence number - ALL ecn-behavior - 2 (as above, I think this should only be in common, but 2 is ok I guess if crc is 7 bit) ACK: 9 packets (high percentage compared to above, but ok I guess) rsf flags (syn,reset,fin) - 1 (why can't these be changed in seq-packets? Maybe add these to one seq packet as well) ttl/hopl - 4 (suggtgest down to max 2 again) tc/tos - 0 (5 for seqeuntial and none here? this seems more reasonable) window - 3 urgent pointer - 1 (common should be enough since this is supposed to be rare) So, generally, I'm for removing fields from packets, and since the WG earlier has received feedback that we have too many packet formats, I suggest we try to remove some of them when we remove fields. (note that I don't have access to the scripts Mark has used to generate these packet formats, so I'm trying to base packet formats on the TCP-BEH draft instead). Now is a REALLY good time for people to comment, 'cause I'll try to change these during the weekend and I don't want to do this over more than once before the next revision of the draft /Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 8 12:25:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08576 for ; Fri, 8 Oct 2004 12:25:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFxiF-0002GX-JU for rohc-web-archive@ietf.org; Fri, 08 Oct 2004 12:35:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxWA-0007b4-KF; Fri, 08 Oct 2004 12:22:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxBO-0006Um-LL for rohc@megatron.ietf.org; Fri, 08 Oct 2004 12:01:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07314 for ; Fri, 8 Oct 2004 12:01:25 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFxLM-0001nv-5p for rohc@ietf.org; Fri, 08 Oct 2004 12:11:44 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <4J954MNT>; Fri, 8 Oct 2004 17:01:40 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2199@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Kristofer Sandlund'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP packet formats (help me!) Date: Fri, 8 Oct 2004 17:01:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ]Ok, now I have a bit better understanding of how to use the list encoding in the ]FN, but it seems to be a bit out of synch with what we've said in tcp-07. Yes, that's because it was written before you and I sorted the list encoding stuff out a month or so back ;-) ] ] In the definition of the packet formats for ROHC-TCP, the most ] frequent type of TCP options are described. Each of these options has ] an uncompressed format, a list_item format and an irregular format. ] OK, to marry them up, Mark has the following for time stamps: tcp_opt_tsopt === { uncompressed_format = type, %[ 8 ] length, %[ 8 ] tsval, %[ 32 ] tsecho; %[ 32 ] default_methods = { type ::= value (8, 8); length ::= value (8, 10); }; format_tsopt_list_item = tsval, %[ 32 ] tsecho, %[ 32 ] { tsval ::= irregular (32); tsopt ::= irregular (32); }; format_tsopt_irregular = tsval, % 16, 24 or 32 bits tsecho, % 16, 24 or 32 bits { tsval ::= ts_lsb; tsecho ::= ts_lsb; }; }; I had this: tcp_timestamp_list_item() === { uncompressed_format = type, length, timestamp_value, timestamp_echo_reply; default_methods = { type ::= uncompressed_value(8, 8); length ::= uncompressed_value(8, 10); }; compressed_format_first = timestamp_value, timestamp_echo_reply { let (this:has_context == false); timestamp_value ::= irregular(32); timestamp_echo_reply ::= irregular(32); }; compressed_format_subsequent = timestamp_value, timestamp_echo_reply { let (this:has_context == true); timestamp_value ::= lsb(16, 0); timestamp_echo_reply ::= lsb(16, 0); }; }; Apart from formatting and naming issues (e.g. Mark has "tsecho", I have "timestamp_echo_reply"), there are two main differences, I have the "let (this:has_context == ..." lines, which Mark doesn't (we need this for the encoding to know which format to use when), and instead of a single lsb encoding, Mark has used a more efficient encoding method, ts_lsb, which still uses lsb fundamentally, but has a couple of different choices depending on how fast it's changing. Actually, I think what may be adding to the confusion here is, I *think* Mark has mixed up his naming of the two encodings, and has called the wrong one "irregular", but basically, his "format_tsopt_list_item" encoding (i.e. the one that encodes the timestamps using irregular encoding) maps onto my "compressed_format_first". I have to go now, but hopefully that will give a clue as to how the rest should be translated. I may be able to help with this next week, then again I may get sucked into a hole... All the best Raffles PS Oh yes, and you're right, the spare bit combination for IP ID is fine to use for "reverse byte order sequential" - the reason the comment says not to use it is because it wasn't currently defined, but reverse byte order is an ideal use - go for it =) Have a nice weekend! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Sun Oct 10 10:00:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11710 for ; Sun, 10 Oct 2004 10:00:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGeQE-000888-JR for rohc-web-archive@ietf.org; Sun, 10 Oct 2004 10:11:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGeB3-0002wr-0v; Sun, 10 Oct 2004 09:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGeAR-0002p2-Kv for rohc@megatron.ietf.org; Sun, 10 Oct 2004 09:55:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11384 for ; Sun, 10 Oct 2004 09:55:17 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGeKm-00082K-AE for rohc@ietf.org; Sun, 10 Oct 2004 10:06:01 -0400 Received: from effnet.com (c83-176-200-103.cust.tele2.se [83.176.200.103]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9ACsFLh021729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 10 Oct 2004 14:54:21 +0200 Message-ID: <41693F1A.6040505@effnet.com> Date: Sun, 10 Oct 2004 15:54:34 +0200 From: Kristofer Sandlund User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] TCP packet formats (help me!) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2199@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A2199@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit > Apart from formatting and naming issues (e.g. Mark has "tsecho", I have > "timestamp_echo_reply"), there are two main differences, I have the > "let (this:has_context == ..." lines, which Mark doesn't (we need this > for the encoding to know which format to use when), and instead of a > single lsb encoding, Mark has used a more efficient encoding method, > ts_lsb, which still uses lsb fundamentally, but has a couple of > different choices depending on how fast it's changing. Actually, I > think what may be adding to the confusion here is, I *think* Mark > has mixed up his naming of the two encodings, and has called the wrong > one "irregular", but basically, his "format_tsopt_list_item" encoding > (i.e. the one that encodes the timestamps using irregular encoding) > maps onto my "compressed_format_first". I'm not sure that I agree here. My view is that if there is a list in the compressed packet, then items are either present in the LIST (_list_item form) or present in the IRREGULAR CHAIN (_irregular form). In the former case, the _list_item has only one possible format and in the latter case then the entry in the list is always empty so it's one format here as well (nothing). Therefore, only one format is needed for creating the list entry for each type, while the irregular stuff is just independent of this and not part of the list. So, what I've done is the following: list_tcp_options(list_length_in_bytes) === { % Length is not known a priori on decompressor, so we use a sentinel. end_of_list_sentinel ::= uncompressed_value(8, 0); end_of_list_padding ::= uncompressed_value(8, 1); mss ::= format_mss_list_item; wscale ::= format_wscale_list_item; tsopt ::= format_tsopt_list_item; sack ::= format_sack_list_item; sack_permitted ::= format_sack_permitted_list_item; eol ::= format_eol_list_item; nop ::= format_nop_list_item; generic ::= format_generic_list_item; }; (the _list_item encodings are almost unchanged from Mark's packet formats). This way, the FN should know that if one of them is not present, no encoding method needs to be applied to that specific item and removing the need for "has_context" stuff that anyway seems to be outside the scope of FN. Or? /Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 11 05:13:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15994 for ; Mon, 11 Oct 2004 05:13:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGwPf-00035u-Ko for rohc-web-archive@ietf.org; Mon, 11 Oct 2004 05:24:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGw9Z-0001eg-9D; Mon, 11 Oct 2004 05:07:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGw45-0000bp-Sl for rohc@megatron.ietf.org; Mon, 11 Oct 2004 05:01:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15302 for ; Mon, 11 Oct 2004 05:01:55 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGwEa-0002rb-FZ for rohc@ietf.org; Mon, 11 Oct 2004 05:12:49 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Oct 2004 10:02:15 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A219B@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'Kristofer Sandlund'" Subject: RE: [rohc] TCP packet formats (help me!) Date: Mon, 11 Oct 2004 10:02:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: "West, Mark" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0722863727==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 This is a multi-part message in MIME format. --===============0722863727== Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0031_01C4AF79.3AF1B840"; protocol="application/x-pkcs7-signature" This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C4AF79.3AF1B840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kris, Thanks for the reply. My own understanding of list encoding here is probably faulty - questions in line below =) However, there was an intention to provide a modicum of generalisation here too, which Mark requested for the packet formats. I don't think anybody was replying to my mails at the time, so I'll fully agree there was no consensus on it, other than between Mark an I, and that was most definitely off the list - it was verbal! So I'll try and describe things below and then we can all discuss it. ]I'm not sure that I agree here. My view is that if there is a list in ]the compressed packet, then items are either present in the LIST ](_list_item form) or present in the IRREGULAR CHAIN (_irregular form). ]In the former case, the _list_item has only one possible format and in ]the latter case then the entry in the list is always empty so it's one ]format here as well (nothing). Hang on isn't it the other way around? I.e. I am reading your above paragraph as though the irregular form is always absent, and the static form is always present, but I thought it was the other way around?: " X = 1 indicates that the item corresponding to the Index is sent in the item 0, ..., item n list. X = 0 indicates that the item corresponding to the Index is not sent. Item 1, ..., item n: Each item corresponds to an XI with X = 1 in XI 1, ..., XI m." RFC 3095 So that items only appear in the list if it isn't in the table already - or is that what you were saying - sorry if I've misunderstood, I think I am perhaps confusing "irregular chain" with "list" - are they the same thing? If not, please help me out =) ]Therefore, only one format is needed for ]creating the list entry for each type, while the irregular stuff is just ]independent of this and not part of the list. ]So, what I've done is the following: ] ]list_tcp_options(list_length_in_bytes) === ]{ ] % Length is not known a priori on decompressor, so we use a sentinel. ] end_of_list_sentinel ::= uncompressed_value(8, 0); ] end_of_list_padding ::= uncompressed_value(8, 1); ] ] mss ::= format_mss_list_item; ] wscale ::= format_wscale_list_item; ] tsopt ::= format_tsopt_list_item; ] sack ::= format_sack_list_item; ] sack_permitted ::= format_sack_permitted_list_item; ] eol ::= format_eol_list_item; ] nop ::= format_nop_list_item; ] generic ::= format_generic_list_item; ]}; ](the _list_item encodings are almost unchanged from Mark's packet formats). ] ]This way, the FN should know that if one of them is not present, no ]encoding method needs to be applied to that specific item and removing ]the need for "has_context" stuff that anyway seems to be outside the ]scope of FN. ]Or? Yes, this makes sense. However, Mark requested access to the context bit (i.e. "X" in 3095), so that we could explicitly provide two different encodings to get maximum efficiency. What this means is, if X=1 we have one encoding, if X=0 we have another. At present, if X=0 we automatically default to using static encoding and hence the item is absent from the list (if I have understood correctly) - this just gives us a mechanism to override that default encoding. Some items, such as end of list, have a permanently fixed value, so there is no point in having two different encodings for that item. Other items fit more nicely into the 3095 pattern and need defining as irregular initially, and after that as static. However a lot of items have e.g. a fixed length, so it is wasteful to send the whole thing as irregular, you just need to send the type and value - the length can be encoded with uncompressed_value. After that, the type and length may be static, but the value may change, so in that case we don't want to just use static encoding by default as it will fail. Having said this, I realise there is a mistake in my example, in that I've encoded the type field for tsopt as uncompressed_value also, which means that the decompressor has no way of telling which list item it is dealing with - D'oh! Does this make sense? I guess it comes down to whether we want the facility to squeeze those extra bits out or not. Raffles ------=_NextPart_000_0031_01C4AF79.3AF1B840 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0zCCAlsw ggHEoAMCAQICAw0tmTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDA2MTI0NTI5WhcNMDUxMDA2MTI0NTI5WjBLMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSgwJgYJKoZIhvcNAQkBFhlSb2JlcnQuRmlua2luZ0By b2tlLmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBPYJpNyrmoZxNpThhngARX294 Jx8TprzFs/UIqLK7R1hvkjYxcbNQy8VDBiWIbYv6c2d+bOVhxHsyhleUSFaAXnyC7PGb6uszzt3c gj74hq0kGO1yK7bBmFJ6uz0AKjXddZ1ZwRDkBsAZ7m8FLXviEVs7oA2MReEJMXuT++1tewIDAQAB ozYwNDAkBgNVHREEHTAbgRlSb2JlcnQuRmlua2luZ0Byb2tlLmNvLnVrMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAqMPZ0XvhAcQl7aBBwbhmD0B5sK5kzEq9F2Pd6DxFEd2nA1DvAwZw mvodHpZ2Pa8TX02OrCQFRU4vsS9GkV7/0W+O9a+9KAym3YbIALsk2zcWIpZ5bqjapA6dpjS9EaS6 xiTtDxUxVxqNLZBiBZjxgi2rYdoo1z0QK0LYNHEmZI8wggMtMIIClqADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAx MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59 LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmU hl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMw ETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+N YFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd 5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAs8wggLLAgEBMGkwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNLZkwCQYFKw4DAhoFAKCCAbwwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDExMDkwMTA4WjAjBgkqhkiG 9w0BCQQxFgQU4uxJX85D13RrETWrZaPaMoS7u3AwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw0tmTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNLZkwDQYJKoZIhvcNAQEBBQAEgYCE QLcuy3WNHqHcNrt1Bau6/gzQ5twVZA0z09oTpqjNdKBH/uqH+EwHzi9AGRi0bkrUaHn/V+S6I5kD R9diIwBVzJM7az1/0o3GYs77YbxnGPbwrKSZF0Q+PfYrstyhX3zLf6QO0tnOCbGNcXWY3eZToDLs Jp9M97NrfuJ2V1yqVAAAAAAAAA== ------=_NextPart_000_0031_01C4AF79.3AF1B840-- --===============0722863727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0722863727==-- From rohc-bounces@ietf.org Mon Oct 11 05:39:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17921 for ; Mon, 11 Oct 2004 05:39:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGwp2-0003YZ-Sq for rohc-web-archive@ietf.org; Mon, 11 Oct 2004 05:50:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGwZ9-00061N-Qz; Mon, 11 Oct 2004 05:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGwYj-0005uA-FI for rohc@megatron.ietf.org; Mon, 11 Oct 2004 05:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17541 for ; Mon, 11 Oct 2004 05:33:35 -0400 (EDT) Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGwjC-0003Rm-DW for rohc@ietf.org; Mon, 11 Oct 2004 05:44:29 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id <4V0T2RK6>; Mon, 11 Oct 2004 10:34:02 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A219C@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'rohc@ietf.org'" Subject: RE: [rohc] TCP packet formats (help me!) Date: Mon, 11 Oct 2004 10:33:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Ooops sorry for the signed message to the list - my bad. Here it is again (unsigned): -----Original Message----- From: Finking, Robert Sent: Monday, October 11, 2004 10:02 AM To: 'Kristofer Sandlund' Cc: West, Mark; 'rohc@ietf.org' Subject: RE: [rohc] TCP packet formats (help me!) Hi Kris, Thanks for the reply. My own understanding of list encoding here is probably faulty - questions in line below =) However, there was an intention to provide a modicum of generalisation here too, which Mark requested for the packet formats. I don't think anybody was replying to my mails at the time, so I'll fully agree there was no consensus on it, other than between Mark an I, and that was most definitely off the list - it was verbal! So I'll try and describe things below and then we can all discuss it. ]I'm not sure that I agree here. My view is that if there is a list in ]the compressed packet, then items are either present in the LIST ](_list_item form) or present in the IRREGULAR CHAIN (_irregular form). ]In the former case, the _list_item has only one possible format and in ]the latter case then the entry in the list is always empty so it's one ]format here as well (nothing). Hang on isn't it the other way around? I.e. I am reading your above paragraph as though the irregular form is always absent, and the static form is always present, but I thought it was the other way around?: " X = 1 indicates that the item corresponding to the Index is sent in the item 0, ..., item n list. X = 0 indicates that the item corresponding to the Index is not sent. Item 1, ..., item n: Each item corresponds to an XI with X = 1 in XI 1, ..., XI m." RFC 3095 So that items only appear in the list if it isn't in the table already - or is that what you were saying - sorry if I've misunderstood, I think I am perhaps confusing "irregular chain" with "list" - are they the same thing? If not, please help me out =) ]Therefore, only one format is needed for ]creating the list entry for each type, while the irregular stuff is just ]independent of this and not part of the list. ]So, what I've done is the following: ] ]list_tcp_options(list_length_in_bytes) === ]{ ] % Length is not known a priori on decompressor, so we use a sentinel. ] end_of_list_sentinel ::= uncompressed_value(8, 0); ] end_of_list_padding ::= uncompressed_value(8, 1); ] ] mss ::= format_mss_list_item; ] wscale ::= format_wscale_list_item; ] tsopt ::= format_tsopt_list_item; ] sack ::= format_sack_list_item; ] sack_permitted ::= format_sack_permitted_list_item; ] eol ::= format_eol_list_item; ] nop ::= format_nop_list_item; ] generic ::= format_generic_list_item; ]}; ](the _list_item encodings are almost unchanged from Mark's packet formats). ] ]This way, the FN should know that if one of them is not present, no ]encoding method needs to be applied to that specific item and removing ]the need for "has_context" stuff that anyway seems to be outside the ]scope of FN. ]Or? Yes, this makes sense. However, Mark requested access to the context bit (i.e. "X" in 3095), so that we could explicitly provide two different encodings to get maximum efficiency. What this means is, if X=1 we have one encoding, if X=0 we have another. At present, if X=0 we automatically default to using static encoding and hence the item is absent from the list (if I have understood correctly) - this just gives us a mechanism to override that default encoding. Some items, such as end of list, have a permanently fixed value, so there is no point in having two different encodings for that item. Other items fit more nicely into the 3095 pattern and need defining as irregular initially, and after that as static. However a lot of items have e.g. a fixed length, so it is wasteful to send the whole thing as irregular, you just need to send the type and value - the length can be encoded with uncompressed_value. After that, the type and length may be static, but the value may change, so in that case we don't want to just use static encoding by default as it will fail. Having said this, I realise there is a mistake in my example, in that I've encoded the type field for tsopt as uncompressed_value also, which means that the decompressor has no way of telling which list item it is dealing with - D'oh! Does this make sense? I guess it comes down to whether we want the facility to squeeze those extra bits out or not. Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 11 05:50:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18968 for ; Mon, 11 Oct 2004 05:50:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGwzj-0003pf-HC for rohc-web-archive@ietf.org; Mon, 11 Oct 2004 06:01:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGwmc-0008S9-8R; Mon, 11 Oct 2004 05:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGwlv-0008KI-Mv for rohc@megatron.ietf.org; Mon, 11 Oct 2004 05:47:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18610 for ; Mon, 11 Oct 2004 05:47:14 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGwwR-0003jv-FH for rohc@ietf.org; Mon, 11 Oct 2004 05:58:08 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9B8kHLh024532 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Oct 2004 10:46:18 +0200 Message-ID: <416A5760.7060904@effnet.com> Date: Mon, 11 Oct 2004 11:50:24 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Finking, Robert" Subject: Re: [rohc] TCP packet formats (help me!) References: <3F2E01E1D7B04F4EBEC92D3FA324D8801A219B@rsys004a.roke.co.uk> In-Reply-To: <3F2E01E1D7B04F4EBEC92D3FA324D8801A219B@rsys004a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: "West, Mark" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Hi Robert! Comments inline. Finking, Robert wrote: > Hi Kris, > > Thanks for the reply. My own understanding of list encoding here is > probably faulty - questions in line below =) However, there was an > intention to provide a modicum of generalisation here too, which Mark > requested for the packet formats. I don't think anybody was replying to my > mails at the time, so I'll fully agree there was no consensus on it, other > than between Mark an I, and that was most definitely off the list - it was > verbal! So I'll try and describe things below and then we can all discuss > it. > > ]I'm not sure that I agree here. My view is that if there is a list in > ]the compressed packet, then items are either present in the LIST > ](_list_item form) or present in the IRREGULAR CHAIN (_irregular form). > ]In the former case, the _list_item has only one possible format and in > ]the latter case then the entry in the list is always empty so it's one > ]format here as well (nothing). > > Hang on isn't it the other way around? I.e. I am reading your above > paragraph as though the irregular form is always absent, and the static > form is always present, but I thought it was the other way around?: Nope. You need to take a look at the TCP profile (-07.txt). The "irregular chain" is something that you use in all packets (but it can be empty if the item is supposed to be non-changing). An option's list item is included there is it is present in the context, and we decided that constuction of this is defined in english. The list_item is present or not present every time a list is trasnmit. > > " X = 1 indicates that the item corresponding to the Index > is sent in the item 0, ..., item n list. > X = 0 indicates that the item corresponding to the Index is > not sent. > > > Item 1, ..., item n: > > Each item corresponds to an XI with X = 1 in XI 1, ..., XI m." > RFC 3095 > > So that items only appear in the list if it isn't in the table already - > or is that what you were saying - sorry if I've misunderstood, I think I > am perhaps confusing "irregular chain" with "list" - are they the same > thing? If not, please help me out =) > > ]Therefore, only one format is needed for > ]creating the list entry for each type, while the irregular stuff is just > ]independent of this and not part of the list. > ]So, what I've done is the following: > ] > ]list_tcp_options(list_length_in_bytes) === > ]{ > ] % Length is not known a priori on decompressor, so we use a > sentinel. > ] end_of_list_sentinel ::= uncompressed_value(8, 0); > ] end_of_list_padding ::= uncompressed_value(8, 1); > ] > ] mss ::= format_mss_list_item; > ] wscale ::= format_wscale_list_item; > ] tsopt ::= format_tsopt_list_item; > ] sack ::= format_sack_list_item; > ] sack_permitted ::= format_sack_permitted_list_item; > ] eol ::= format_eol_list_item; > ] nop ::= format_nop_list_item; > ] generic ::= format_generic_list_item; > ]}; > ](the _list_item encodings are almost unchanged from Mark's packet > formats). > ] > ]This way, the FN should know that if one of them is not present, no > ]encoding method needs to be applied to that specific item and removing > ]the need for "has_context" stuff that anyway seems to be outside the > ]scope of FN. > ]Or? > > Yes, this makes sense. However, Mark requested access to the context bit > (i.e. "X" in 3095), so that we could explicitly provide two different > encodings to get maximum efficiency. What this means is, if X=1 we have > one encoding, if X=0 we have another. At present, if X=0 we automatically > default to using static encoding and hence the item is absent from the > list (if I have understood correctly) - this just gives us a mechanism to > override that default encoding. > Noooooo. When X=0 there is no item whatsoever. It is always empty, both in 3095 and in TCP. > Some items, such as end of list, have a permanently fixed value, so there > is no point in having two different encodings for that item. Other items > fit more nicely into the 3095 pattern and need defining as irregular > initially, and after that as static. However a lot of items have e.g. a > fixed length, so it is wasteful to send the whole thing as irregular, you > just need to send the type and value - the length can be encoded with > uncompressed_value. After that, the type and length may be static, but the > value may change, so in that case we don't want to just use static > encoding by default as it will fail. > Again. Irregular chain, not in list. You don't win anything by having multiple formats when we have the irregular chain instead. The list itself should only be sent when the structure of the list changes (insert/delete of new options). > Having said this, I realise there is a mistake in my example, in that I've > encoded the type field for tsopt as uncompressed_value also, which means > that the decompressor has no way of telling which list item it is dealing > with - D'oh! Some of the items will have reserved index values (see tcp-07) and therefore only a few of them need to explicitly send type. /Kristofer > > Does this make sense? > > I guess it comes down to whether we want the facility to squeeze those > extra bits out or not. > > Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 12 05:17:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02252 for ; Tue, 12 Oct 2004 05:17:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHIxB-0000fq-As for rohc-web-archive@ietf.org; Tue, 12 Oct 2004 05:28:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHIhT-0000tc-Fo; Tue, 12 Oct 2004 05:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHIgP-0000ZW-LJ for rohc@megatron.ietf.org; Tue, 12 Oct 2004 05:11:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01852 for ; Tue, 12 Oct 2004 05:10:59 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHIr7-0000Yz-3m for rohc@ietf.org; Tue, 12 Oct 2004 05:22:05 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9C9AxWR019999 for ; Tue, 12 Oct 2004 11:10:59 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 11:10:58 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4V8DY17P>; Tue, 12 Oct 2004 11:10:58 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Kristofer Sandlund'" , "Finking, Robert" Subject: RE: [rohc] TCP packet formats (help me!) Date: Tue, 12 Oct 2004 11:10:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 12 Oct 2004 09:10:58.0985 (UTC) FILETIME=[635D8990:01C4B03B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: "West, Mark" , "'rohc@ietf.org'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e What Kristofer has explained is how I also thought it was supposed to fit together. /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Kristofer Sandlund > Sent: den 11 oktober 2004 11:50 > To: Finking, Robert > Cc: West, Mark; 'rohc@ietf.org' > Subject: Re: [rohc] TCP packet formats (help me!) > > > Hi Robert! > Comments inline. > > Finking, Robert wrote: > > Hi Kris, > > > > Thanks for the reply. My own understanding of list encoding here is > > probably faulty - questions in line below =) However, there was an > > intention to provide a modicum of generalisation here too, > which Mark > > requested for the packet formats. I don't think anybody was > replying to my > > mails at the time, so I'll fully agree there was no > consensus on it, other > > than between Mark an I, and that was most definitely off > the list - it was > > verbal! So I'll try and describe things below and then we > can all discuss > > it. > > > > ]I'm not sure that I agree here. My view is that if there > is a list in > > ]the compressed packet, then items are either present in the LIST > > ](_list_item form) or present in the IRREGULAR CHAIN > (_irregular form). > > ]In the former case, the _list_item has only one possible > format and in > > ]the latter case then the entry in the list is always empty > so it's one > > ]format here as well (nothing). > > > > Hang on isn't it the other way around? I.e. I am reading your above > > paragraph as though the irregular form is always absent, > and the static > > form is always present, but I thought it was the other way around?: > > Nope. You need to take a look at the TCP profile (-07.txt). > The "irregular chain" is something that you use in all > packets (but it can be > empty if the item is supposed to be non-changing). An > option's list item is > included there is it is present in the context, and we > decided that constuction > of this is defined in english. > The list_item is present or not present every time a list is trasnmit. > > > > > " X = 1 indicates that the item corresponding to the Index > > is sent in the item 0, ..., item n list. > > X = 0 indicates that the item corresponding to > the Index is > > not sent. > > > > > > Item 1, ..., item n: > > > > Each item corresponds to an XI with X = 1 in XI > 1, ..., XI m." > > RFC 3095 > > > > So that items only appear in the list if it isn't in the > table already - > > or is that what you were saying - sorry if I've > misunderstood, I think I > > am perhaps confusing "irregular chain" with "list" - are > they the same > > thing? If not, please help me out =) > > > > ]Therefore, only one format is needed for > > ]creating the list entry for each type, while the irregular > stuff is just > > ]independent of this and not part of the list. > > ]So, what I've done is the following: > > ] > > ]list_tcp_options(list_length_in_bytes) === > > ]{ > > ] % Length is not known a priori on decompressor, > so we use a > > sentinel. > > ] end_of_list_sentinel ::= uncompressed_value(8, 0); > > ] end_of_list_padding ::= uncompressed_value(8, 1); > > ] > > ] mss ::= format_mss_list_item; > > ] wscale ::= format_wscale_list_item; > > ] tsopt ::= format_tsopt_list_item; > > ] sack ::= format_sack_list_item; > > ] sack_permitted ::= format_sack_permitted_list_item; > > ] eol ::= format_eol_list_item; > > ] nop ::= format_nop_list_item; > > ] generic ::= format_generic_list_item; > > ]}; > > ](the _list_item encodings are almost unchanged from Mark's packet > > formats). > > ] > > ]This way, the FN should know that if one of them is not present, no > > ]encoding method needs to be applied to that specific item > and removing > > ]the need for "has_context" stuff that anyway seems to be > outside the > > ]scope of FN. > > ]Or? > > > > Yes, this makes sense. However, Mark requested access to > the context bit > > (i.e. "X" in 3095), so that we could explicitly provide two > different > > encodings to get maximum efficiency. What this means is, if > X=1 we have > > one encoding, if X=0 we have another. At present, if X=0 we > automatically > > default to using static encoding and hence the item is > absent from the > > list (if I have understood correctly) - this just gives us > a mechanism to > > override that default encoding. > > > > Noooooo. When X=0 there is no item whatsoever. It is always > empty, both in 3095 > and in TCP. > > > Some items, such as end of list, have a permanently fixed > value, so there > > is no point in having two different encodings for that > item. Other items > > fit more nicely into the 3095 pattern and need defining as irregular > > initially, and after that as static. However a lot of items > have e.g. a > > fixed length, so it is wasteful to send the whole thing as > irregular, you > > just need to send the type and value - the length can be > encoded with > > uncompressed_value. After that, the type and length may be > static, but the > > value may change, so in that case we don't want to just use static > > encoding by default as it will fail. > > > > Again. Irregular chain, not in list. You don't win anything > by having multiple > formats when we have the irregular chain instead. The list > itself should only be > sent when the structure of the list changes (insert/delete of > new options). > > > Having said this, I realise there is a mistake in my > example, in that I've > > encoded the type field for tsopt as uncompressed_value > also, which means > > that the decompressor has no way of telling which list item > it is dealing > > with - D'oh! > > Some of the items will have reserved index values (see > tcp-07) and therefore > only a few of them need to explicitly send type. > > /Kristofer > > > > > Does this make sense? > > > > I guess it comes down to whether we want the facility to > squeeze those > > extra bits out or not. > > > > Raffles > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 12 09:03:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17494 for ; Tue, 12 Oct 2004 09:03:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMUB-0004he-Td for rohc-web-archive@ietf.org; Tue, 12 Oct 2004 09:14:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHME5-0007aO-M3; Tue, 12 Oct 2004 08:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHM4i-0005Cg-HP for rohc@megatron.ietf.org; Tue, 12 Oct 2004 08:48:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16360 for ; Tue, 12 Oct 2004 08:48:19 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMFR-0004PX-B8 for rohc@ietf.org; Tue, 12 Oct 2004 08:59:26 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 12 Oct 2004 13:48:35 +0100 Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8801A21A9@rsys004a.roke.co.uk> From: "Finking, Robert" To: "'rohc@ietf.org'" , "'Lars-Erik Jonsson (LU/EAB)'" , "'Kristofer Sandlund'" , Eilert Brinkmann Date: Tue, 12 Oct 2004 13:48:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "West, Mark" , Carsten Bormann , "Ghyslain Pelletier \(LU/EAB\)" Subject: [rohc] RE: NEW TCP packet formats X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 PS we seem to have strayed off the list again.... (CC'd to the list) -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: Tuesday, October 12, 2004 10:25 AM To: 'Kristofer Sandlund'; Eilert Brinkmann Cc: Carsten Bormann; Ghyslain Pelletier (LU/EAB); West, Mark; Finking, Robert Subject: RE: NEW TCP packet formats > My view is that we really have a few different "modules" > in the packet formats: > static_chain (IR only) > dynamic_chain (IR, IR-DYN) > replicate_chain (IR-CR) > irregular_chain (all CO packets) > base_header (all CO packets) > tcp_options_list (which is special, let me get back to this one) > > Where sections 6.5.1-6.5.3 of tcp-07 + the new text I proposed > the other week describes which of these "modules" that the > compressor is going to use / decompressor is going to expect. Makes perfect sense to me! > Therefore, the disambiguating (is this a word?) is handled by > which packet format I have I have. So, no need to have any > form of logic to help decisions on these in the structures > since the packet format decides what to use for chains and > base header. Is that what you FN-people also feel or do you > still feel that the current pf are lacking in this sense? > If my understanding is correct, I just think that we should > use the text I proposed on the list earlier and beef it up > (perhaps even with a small example section) so that the user > understands that this is how compressed packets are > assembled from the items in the FN. Agree, I assume Ghyslain is updating the TCP profile draft, we should get a new (WGLC-ready?) version before the ID cut-off. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 12 17:23:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13696 for ; Tue, 12 Oct 2004 17:23:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUIV-0003Fb-0V for rohc-web-archive@ietf.org; Tue, 12 Oct 2004 17:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTQ6-0004iS-Ej; Tue, 12 Oct 2004 16:38:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSxV-0002tY-1G; Tue, 12 Oct 2004 16:09:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28085; Tue, 12 Oct 2004 16:09:19 -0400 (EDT) Message-Id: <200410122009.QAA28085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 12 Oct 2004 16:09:19 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-over-reordering-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets Author(s) : G. Pelletier, et al. Filename : draft-ietf-rohc-over-reordering-00.txt Pages : 20 Date : 2004-10-12 RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-over-reordering-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-over-reordering-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-12160534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-over-reordering-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-over-reordering-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-12160534.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Tue Oct 12 17:25:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13977 for ; Tue, 12 Oct 2004 17:25:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUJo-0003Lm-CZ for rohc-web-archive@ietf.org; Tue, 12 Oct 2004 17:36:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTQ9-0004l9-N2; Tue, 12 Oct 2004 16:38:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSxk-00030M-Tq; Tue, 12 Oct 2004 16:09:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28144; Tue, 12 Oct 2004 16:09:35 -0400 (EDT) Message-Id: <200410122009.QAA28144@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 12 Oct 2004 16:09:35 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-07.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : ROHC Implementer's Guide Author(s) : L. Jonsson, P. Kremer Filename : draft-ietf-rohc-rtp-impl-guide-07.txt Pages : 21 Date : 2004-10-12 This document describes common misinterpretations and some ambiguous points of ROHC [RFC 3095], which defines the framework and four profiles of a robust and efficient header compression scheme. These points have been identified by the members of the ROHC working group during different interoperability test events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-rtp-impl-guide-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-12160540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-12160540.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Wed Oct 13 07:30:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15938 for ; Wed, 13 Oct 2004 07:30:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhVW-0002S7-FH for rohc-web-archive@ietf.org; Wed, 13 Oct 2004 07:41:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhAG-0008LK-Hl; Wed, 13 Oct 2004 07:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHh7H-0007aw-HI for rohc@megatron.ietf.org; Wed, 13 Oct 2004 07:16:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14168 for ; Wed, 13 Oct 2004 07:16:18 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhHy-00023R-MB for rohc@ietf.org; Wed, 13 Oct 2004 07:27:37 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9DBG6RU006064 for ; Wed, 13 Oct 2004 13:16:06 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 13:16:06 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4V81DL6L>; Wed, 13 Oct 2004 13:16:05 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "Lars-Erik Jonsson (LU/EAB)" , "'rohc@ietf.org'" Subject: RE: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095 Date: Wed, 13 Oct 2004 13:16:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Oct 2004 11:16:06.0749 (UTC) FILETIME=[08C128D0:01C4B116] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 > > 8.12. When to expect UOR-2 ACKs in O-mode > > Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in > O-mode, and explains a conceptual algorithm for a compressor to > determine whether such ACKs can be expected from the decompressor, > simply using a condition based on unspecified parameters > k_3 and n_3. However, what is not clearly pointed out is the > importance of being very careful when implementing this > confidence algorithm, as using an incorrect expectation on > UOR-2 ACKs as a basis for compressor behavior will significantly > degrade the compression performance. If a compressor > implementation wants to adapt its optimistic approach behavior > on potential UOR-2 ACK usage, the confidence algorithm for > determining UOR-2 ACK usage must be carefully designed, with > k_3=n_3>>1, as UOR-2 ACKs can be sent from a decompressor for I think I agree that k_3 and n_3 must be much larger than 1, but I think that k_3=n_3>>1 is wrong (i.e. the "k_3=n_3" bit) since this essentially means "for a number X of consecutive UOR-2". This would also mean that in the presence of packet losses (either compressed packets or ACKs), such confidence would likely not be achieved very often - if k_3 and n_3 are much larger than 1 and the packet loss rate is somewhat high. > other purposes than to actually acknowledge the UOR-2 packet, > e.g. to send feedback data such as clock resolution, or to > initiate a mode transfer. Before adapting a compressor to the > potential use of UOR-2 ACKs, the implementer must ensure all > these aspects are considered in the confidence algorithm. > > It should again be noted that the use of UOR-2 ACKs in O-mode > is indeed optional, so a decompressor can send ACKs for other > purposes than actually acking the UOR-2, without then having > to continue sending them for all UOR-2. Similarly, compressor > implementations can totally ignore UOR-2 ACKs for the purpose > of adapting the optimistic approach strategies. Imo, the above text should be rewritten to provide a stronger recommendation to avoid having compressors trying to create confidence about acks to UOR-2 and just use the optimistic approach as usual. I think this part in itself is a fair example of overspecification - would 3095 be rewritten I doubt I would like to see that text in. The above suggested text should then be moved as the first paragraph of the section. I think that this section of the implementer's guide (8.12. When to expect UOR-2 ACKs in O-mode) should be renamed "8.12. Expecting UOR-2 ACKs in O-mode". "When to expect" is still as suggestive as 3095 is regarding this. Sorry I couldn't comment before you updated the draft, I was sick in bed for a few days... /Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 13 07:38:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16688 for ; Wed, 13 Oct 2004 07:38:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhdm-0002e6-UV for rohc-web-archive@ietf.org; Wed, 13 Oct 2004 07:50:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhLF-00037T-Lu; Wed, 13 Oct 2004 07:30:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHhDC-0000ZS-Dw for rohc@megatron.ietf.org; Wed, 13 Oct 2004 07:22:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14953 for ; Wed, 13 Oct 2004 07:22:26 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHhNt-0002Ba-Ma for rohc@ietf.org; Wed, 13 Oct 2004 07:33:44 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9DBMARU007686 for ; Wed, 13 Oct 2004 13:22:13 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 13:22:10 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4V81DNYC>; Wed, 13 Oct 2004 13:22:09 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Ghyslain Pelletier (LU/EAB)" , "'rohc@ietf.org'" Subject: RE: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095 Date: Wed, 13 Oct 2004 13:22:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Oct 2004 11:22:10.0255 (UTC) FILETIME=[E16BC5F0:01C4B116] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Comments inline... > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB) > Sent: den 13 oktober 2004 13:16 > To: Lars-Erik Jonsson (LU/EAB); 'rohc@ietf.org' > Subject: RE: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095 > > > > > > 8.12. When to expect UOR-2 ACKs in O-mode > > > > Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in > > O-mode, and explains a conceptual algorithm for a compressor to > > determine whether such ACKs can be expected from the > decompressor, > > simply using a condition based on unspecified parameters > > k_3 and n_3. However, what is not clearly pointed out is the > > importance of being very careful when implementing this > > confidence algorithm, as using an incorrect expectation on > > UOR-2 ACKs as a basis for compressor behavior will significantly > > degrade the compression performance. If a compressor > > implementation wants to adapt its optimistic approach behavior > > on potential UOR-2 ACK usage, the confidence algorithm for > > determining UOR-2 ACK usage must be carefully designed, with > > k_3=n_3>>1, as UOR-2 ACKs can be sent from a decompressor for > > I think I agree that k_3 and n_3 must be much larger than 1, > but I think that k_3=n_3>>1 is wrong (i.e. the "k_3=n_3" bit) > since this essentially means "for a number X of consecutive > UOR-2". This would also mean that in the presence of packet > losses (either compressed packets or ACKs), such confidence > would likely not be achieved very often - if k_3 and n_3 are > much larger than 1 and the packet loss rate is somewhat high. True, k_3 and n_3 is not very useful tools to describe what a compressor should do to get confidence. I'll rewrite this. > > other purposes than to actually acknowledge the UOR-2 packet, > > e.g. to send feedback data such as clock resolution, or to > > initiate a mode transfer. Before adapting a compressor to the > > potential use of UOR-2 ACKs, the implementer must ensure all > > these aspects are considered in the confidence algorithm. > > > > It should again be noted that the use of UOR-2 ACKs in O-mode > > is indeed optional, so a decompressor can send ACKs for other > > purposes than actually acking the UOR-2, without then having > > to continue sending them for all UOR-2. Similarly, compressor > > implementations can totally ignore UOR-2 ACKs for the purpose > > of adapting the optimistic approach strategies. > > Imo, the above text should be rewritten to provide a stronger > recommendation to avoid having compressors trying to create > confidence about acks to UOR-2 and just use the optimistic > approach as usual. I think this part in itself is a fair > example of overspecification - would 3095 be rewritten I > doubt I would like to see that text in. The above suggested > text should then be moved as the first paragraph of the section. That would be fine with me, I agree with your motivation. > I think that this section of the implementer's guide (8.12. > When to expect UOR-2 ACKs in O-mode) should be renamed "8.12. > Expecting UOR-2 ACKs in O-mode". "When to expect" is still as > suggestive as 3095 is regarding this. True! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 14 04:41:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19360 for ; Thu, 14 Oct 2004 04:41:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI1MK-0004VX-M4 for rohc-web-archive@ietf.org; Thu, 14 Oct 2004 04:53:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI13s-0000zh-8O; Thu, 14 Oct 2004 04:34:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI12h-0000Yj-QE for rohc@megatron.ietf.org; Thu, 14 Oct 2004 04:33:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18932 for ; Thu, 14 Oct 2004 04:32:54 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI1Dl-0004Oo-6F for rohc@ietf.org; Thu, 14 Oct 2004 04:44:26 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9E8WqWR020252 for ; Thu, 14 Oct 2004 10:32:52 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 10:32:52 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4V81LFF6>; Thu, 14 Oct 2004 10:32:52 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Finking, Robert'" , "'Kristofer Sandlund'" , "'Carsten Bormann'" Date: Thu, 14 Oct 2004 10:32:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Oct 2004 08:32:52.0762 (UTC) FILETIME=[657F17A0:01C4B1C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: "'Eilert Brinkmann'" , "'West, Mark'" , "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" Subject: [rohc] RE: NEW TCP packet formats X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a > -----Original Message----- > From: Finking, Robert [mailto:robert.finking@roke.co.uk] > Sent: den 14 oktober 2004 10:15 > To: 'Kristofer Sandlund'; Carsten Bormann > Cc: Eilert Brinkmann; Ghyslain Pelletier (LU/EAB); West, > Mark; Lars-Erik > Jonsson (LU/EAB) > Subject: RE: NEW TCP packet formats > > > > ]Carsten Bormann wrote: > ]> On Oct 13 2004, at 18:54 Uhr, Eilert Brinkmann wrote: > ]> > ]>> 3. Extend the encoding method descriptions in the draft > to explicitly > ]>> state that compressed_value binds uncomp_length with 0 and > ]>> uncompressed_value binds comp_length with 0. This > would have the > ]>> advantage that there would be no cases in which > encoding methods > ]>> leave either the comp_* or the uncomp_* attributes > undefined. (But > ]>> one would still be free not to mention a field in one > of the field > ]>> order lists.) Effectively, this would make the following three > ]>> encodings equivalent: > ]>> > ]>> compressed_value(0, 0) > ]>> uncompressed_value(0, 0) > ]>> irregular(0) > ]> > ]> > ]> I'm a big fan of this. > ]> I don't see a need for a field "not to have" one of the two sides > ]> (compressed and uncompressed) -- as you say, not > mentioning the field in > ]> the respective field list is sufficient for that to have > no effect on > ]> the parent field. > ]> Not having the concept of "not having one side" simplifies the > ]> description significantly. > ]> > ]> Gruesse, Carsten > ] > ]I agree that this seems like a good solution. > ] > > Missed the rest of the thread, but whatever the original > reason, I think this is a good idea. Otherwise you could > specify both compressed_value and uncompressed_value for the > same field name, but the two would be completely unrelated, > which would be confusing. I like this idea a > lot =) > > Cheers > > Raffles It might not look like it, but I am actually following these threads ; ) ... and my first reaction was also that this seems best. I don't like option 1) because the field does sometimes appear in the uncompressed header (and that would somewhat go against the idea behind uncompressed_format), I don't like 2) because it does abuse the irregular coding method. And option 3 does make complete sense! (so no surprise from my side later on ; ) I will do the necessary changes to the FN draft. BTW, I am copying the mailing list with included original message from Eilert - because this leads to a change to the draft. /Ghyslain > -----Original Message----- > From: Eilert Brinkmann [mailto:eilert@tzi.org] > Sent: den 13 oktober 2004 18:55 > To: Kristofer Sandlund > Cc: Carsten Bormann; Lars-Erik Jonsson (LU/EAB); Ghyslain Pelletier > (LU/EAB); 'West, Mark'; Finking, Robert > Subject: Re: NEW TCP packet formats > > > Kristofer Sandlund wrote: > > ********** > > format_not_present = item, %[ 0 ] > > { > > let (flag == 0); > > > > item ::= compressed_value (0, 0); % FIXME: > uncompressed_value? > > }; > > No, it should be "compressed value" since this field is not even > > present in the uncompressed packet in this case. The field is only > > sometimes in there. > > No, it has a length of 0 bits in this case (which is true for the > compressed side as well), but according to the specification it is > present. The complete structure looks like this: > > optional32 (flag) === > { > uncompressed_format = item; % 0 or 32 bits > > format_present = item, %[ 32 ] > { > let (flag == 1); > item ::= irregular (32); > }; > > format_not_present = item, %[ 0 ] > { > let (flag == 0); > item ::= compressed_value (0, 0); > }; > }; > > Formally the field "item" is always part of the uncompressed format, > although it's length might be 0 bits, so the field's uncompressed side > must be bound. According to the current FN draft compressed_value "is > used to define fields in the compressed header for which there is no > counter-part in the uncompressed header", i.e. we can not use it in > cases like this where the field is mentioned in the field order list > of uncompressed_format. The description does not even say that the > compressed_value encoding method binds uncomp_length with 0, so it's > effect on the uncompressed side is currently undefined. (With > uncompressed_value it's the other way around.) > > I see three solutions: > > 1. Remove item from the field order list in format_not_present and use > the uncompressed_value encoding method to bind item:uncomp_value > with 0, i.e. the compressed format's field list will be empty: > > format_not_present = > { > let (flag == 0); > item ::= uncompressed_value (0, 0); > }; > > 2. Use irregular(0) to bind item:uncomp_length as well as > item:comp_length with 0: > > format_not_present = item, %[ 0 ] > { > let (flag == 0); > item ::= irregular (0); > }; > > A variant of this would be the use of only one compressed format in > this structure with a variable-length irregular encoding as once > suggested by Robert: > > optional32 (flag) === > { > uncompressed_format = item; % 0 or 32 bits > > compressed_format = item, % 0 or 32 bits > { > let (flag == 0 || flag == 1); > item ::= irregular (32 * flag); > }; > }; > > 3. Extend the encoding method descriptions in the draft to explicitly > state that compressed_value binds uncomp_length with 0 and > uncompressed_value binds comp_length with 0. This would have the > advantage that there would be no cases in which encoding methods > leave either the comp_* or the uncomp_* attributes undefined. (But > one would still be free not to mention a field in one of the field > order lists.) Effectively, this would make the following three > encodings equivalent: > > compressed_value(0, 0) > uncompressed_value(0, 0) > irregular(0) > > Am I wrong with this or does anyone see other and possibly better > solutions? > > Regards > > Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 15 06:14:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13394 for ; Fri, 15 Oct 2004 06:14:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIPHl-00033G-7t for rohc-web-archive@ietf.org; Fri, 15 Oct 2004 06:26:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIP3K-0004mj-AP; Fri, 15 Oct 2004 06:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CINBb-0004PQ-2G for rohc@megatron.ietf.org; Fri, 15 Oct 2004 04:11:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03823 for ; Fri, 15 Oct 2004 04:11:35 -0400 (EDT) From: sauragupta@hssworld.com Received: from [61.16.168.135] (helo=hssworld.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CINMs-0000Vi-Nw for rohc@ietf.org; Fri, 15 Oct 2004 04:23:20 -0400 Received: from pragati.blr.hss.hns.com (pragati.hss.hns.com [172.17.33.22]) by hssworld.com (8.11.6/8.11.6) with ESMTP id i9F84FC31045 for ; Fri, 15 Oct 2004 13:34:17 +0530 To: rohc@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Fri, 15 Oct 2004 13:40:20 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5|September 18, 2003) at 10/15/2004 01:41:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Fri, 15 Oct 2004 06:11:12 -0400 Subject: [rohc] Bug in bytecode of Simplified LZ77 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi, Reference In the Section 4.1 of the draft mentioned above input-bit- register label is missing. There should always be a input-bit-register at 68-69 memory address in the UDVM. Therefore the bytecode generated by a parser is wrong. Decompression failure will occur when decompression pointer (LSB) is not in the range of 0 to 7. Any pointers and comments are welcome. Regards Saurabh Hughes Software System www.hssworld.com *********************** HSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 15 06:52:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16379 for ; Fri, 15 Oct 2004 06:52:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIPsR-0003uL-3K for rohc-web-archive@ietf.org; Fri, 15 Oct 2004 07:04:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIPfi-0004Qc-SQ; Fri, 15 Oct 2004 06:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIPKm-0008SM-Qk for rohc@megatron.ietf.org; Fri, 15 Oct 2004 06:29:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14451 for ; Fri, 15 Oct 2004 06:29:14 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIPVy-0003KF-9L for rohc@ietf.org; Fri, 15 Oct 2004 06:41:00 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9FAT4WR021311 for ; Fri, 15 Oct 2004 12:29:04 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 12:29:04 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4J5H8ZYD>; Fri, 15 Oct 2004 12:29:04 +0200 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: "'sauragupta@hssworld.com'" Subject: RE: [rohc] Bug in bytecode of Simplified LZ77 Date: Fri, 15 Oct 2004 12:28:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Oct 2004 10:29:04.0883 (UTC) FILETIME=[CB9E1430:01C4B2A1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi Saurabh, First of all, there is a version 1 of the user guide document, but this is not important regarding your problem. Second, the input bit order register is checked when INPUT-BITS or INPUT-HUFFMAN instructions are executed. After setting the decompressed pointer (that in this case has the same address as of the input bit order register), no such instructions can be found, thus no decompression failure would occur. See also section 8.2 in RFC 3320: Note that the INPUT-BITS and INPUT-HUFFMAN instructions retrieve a stream of individual compressed bits from the dispatcher. To provide bitwise compatibility with various well-known compression algorithms, the input_bit_order register can modify the order in which individual bits are passed within a byte. br/Zacco -----Original Message----- From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of sauragupta@hssworld.com Sent: Friday, October 15, 2004 10:10 AM To: rohc@ietf.org Subject: [rohc] Bug in bytecode of Simplified LZ77 Hi, Reference In the Section 4.1 of the draft mentioned above input-bit- register label is missing. There should always be a input-bit-register at 68-69 memory address in the UDVM. Therefore the bytecode generated by a parser is wrong. Decompression failure will occur when decompression pointer (LSB) is not in the range of 0 to 7. Any pointers and comments are welcome. Regards Saurabh Hughes Software System www.hssworld.com *********************** HSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Sun Oct 17 00:49:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05870 for ; Sun, 17 Oct 2004 00:49:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ3Aq-0003XT-R0 for rohc-web-archive@ietf.org; Sun, 17 Oct 2004 01:01:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2xo-0001jt-DI; Sun, 17 Oct 2004 00:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2wm-0001Un-0d; Sun, 17 Oct 2004 00:47:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05714; Sun, 17 Oct 2004 00:47:01 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ38G-0003Ts-RG; Sun, 17 Oct 2004 00:59:11 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9H4kHHC028980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 16 Oct 2004 21:46:17 -0700 (PDT) Received: from [10.50.68.206] (qconnect-10-50-68-206.qualcomm.com [10.50.68.206]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9H4kEbZ020698; Sat, 16 Oct 2004 21:46:15 -0700 (PDT) Message-ID: <4171F917.5010702@san.rr.com> Date: Sat, 16 Oct 2004 21:46:15 -0700 From: Ramin Rezaiifar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.6.4.0b X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet-Drafts@ietf.org Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-over-reordering-00.txt References: <200410122009.QAA28085@ietf.org> In-Reply-To: <200410122009.QAA28085@ietf.org> X-Spam-Score: 1.1 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: rohc@ietf.org, lars-erik.jonsson@ericsson.com, i-d-announce@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1497272012==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============1497272012== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
The values in the 3rd column of the table on page 7 don't seem to be correct. 
For example, when k=4, (2^k-1)-p is equal to 16-1-1=14.
The values in the 3rd column are computed as: 2^(k-1)-1  (but I think it should really be (2^k-1)-p)

-Ramin Rezaiifar
raminr@qualcomm.com


Internet-Drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Robust Header Compression Working Group of the IETF.

	Title		: RObust Header Compression (ROHC): ROHC over 
			  Channels that can Reorder Packets
	Author(s)	: G. Pelletier, et al.
	Filename	: draft-ietf-rohc-over-reordering-00.txt
	Pages		: 20
	Date		: 2004-10-12
	
RObust Header Compression (ROHC), RFC 3095, defines a framework for
   header compression, along with a number of compression protocols
   (profiles). One operating assumption for the profiles defined in RFC
   3095 is that the channel between compressor and decompressor is
   required to maintain packet ordering. This document discusses aspects
   of using ROHC over channels that can reorder packets. It provides
   guidelines on how to implement existing profiles over such channels,
   as well as suggestions for the design of new profiles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rohc-over-reordering-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-over-reordering-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

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

--===============1497272012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1497272012==-- From rohc-bounces@ietf.org Wed Oct 20 05:27:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14138 for ; Wed, 20 Oct 2004 05:27:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCx5-0003m5-BD for rohc-web-archive@ietf.org; Wed, 20 Oct 2004 05:40:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKAzJ-00078d-81; Wed, 20 Oct 2004 03:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcHM-00069o-TC for rohc@megatron.ietf.org; Fri, 15 Oct 2004 20:18:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08265 for ; Fri, 15 Oct 2004 20:18:35 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.198] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcSp-0001Pk-SN for rohc@ietf.org; Fri, 15 Oct 2004 20:30:28 -0400 Received: by mproxy.gmail.com with SMTP id 75so60684rnk for ; Fri, 15 Oct 2004 17:18:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=cfW3f2uI1ALbneBvwW7H5Mqws6ozHF3cAjmR8aKHEskJHGHxkzFNZ0QiB+P5Ik7INbtJ+0jkJryD/Jdcgo62Sj3pPY7osmVyO/yfv5011yXeIxpam6M5TmghZ/HV74RGwkq/oePO1tAB/lRNiIt8pgCqI97YulGIe6aY3gOckR8 Received: by 10.38.151.68 with SMTP id y68mr489973rnd; Fri, 15 Oct 2004 17:18:35 -0700 (PDT) Received: by 10.38.76.43 with HTTP; Fri, 15 Oct 2004 17:18:35 -0700 (PDT) Message-ID: Date: Fri, 15 Oct 2004 17:18:35 -0700 From: Rohit Kapoor To: rohc@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Oct 2004 03:34:07 -0400 Subject: [rohc] Reordered Packets X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohit Kapoor List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi, I was wondering what the thinking is regarding enabling RoHC to handle reordering. Not being able to handle reordering is one issue that has been cited as a drawback of RoHC. My feeling is however, that this is not an inherent limitation of RoHC but merely an artifact of a parameter value specified in RFC 3095. Specifically, from section 5.7 of RFC 3095, SN: The compressed RTP Sequence Number. Compressed with W-LSB. The interpretation intervals, see section 4.5.1, are defined as follows: p = 1 if bits(SN) <= 4 p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 p = 1 can handle a reordering of 1. Higher values of p can handle more reordering. The higher value, of course, slightly reduces RoHCs robustness to "continuous" dropped packets. Also, Section 4.5.1 in RFC 3095 already alludes to this possiblity. Specifically, d) For field values that are expected to undergo small negative changes and larger positive changes, such as the RTP TS for video, or RTP SN when there is misordering, p can be set to 2^(k-2) - 1. The interval becomes [v_ref - 2^(k-2) + 1, v_ref + 3 * 2^(k-2)], i.e., 3/4 of the interval is used for positive changes. Can someone please comment on this reordering issue? I dont see much drawback to setting p to a higher value when the environment has higher reordering. Was there a reason I am missing that p is set to 1? Is there any drawback from setting it to a higher value? I would appreciate responses. Thanks, Rohit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 20 07:53:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25098 for ; Wed, 20 Oct 2004 07:53:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKFEn-00071x-FH for rohc-web-archive@ietf.org; Wed, 20 Oct 2004 08:06:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEAm-0005MH-QR; Wed, 20 Oct 2004 06:58:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDde-0006oz-At for rohc@megatron.ietf.org; Wed, 20 Oct 2004 06:24:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17208 for ; Wed, 20 Oct 2004 06:24:06 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKDpt-0004pL-Jp for rohc@ietf.org; Wed, 20 Oct 2004 06:36:57 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9K9N3Lh026863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Oct 2004 11:23:04 +0200 Message-ID: <41763CC2.9080308@effnet.com> Date: Wed, 20 Oct 2004 12:24:02 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohit Kapoor Subject: Re: [rohc] Reordered Packets References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Hi! I would refer you to the draft about that specific topic. http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-00.txt BR, Kristofer Sandlund, Effnet AB Rohit Kapoor wrote: > Hi, > > I was wondering what the thinking is regarding enabling RoHC to handle > reordering. > > Not being able to handle reordering is one issue that has been cited > as a drawback of RoHC. My feeling is however, that this is not an > inherent limitation of RoHC but merely an artifact of a parameter > value specified in RFC 3095. Specifically, from section 5.7 of RFC > 3095, > > SN: The compressed RTP Sequence Number. > > Compressed with W-LSB. The interpretation intervals, see section > 4.5.1, are defined as follows: > > p = 1 if bits(SN) <= 4 > p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 > > p = 1 can handle a reordering of 1. Higher values of p can handle more > reordering. The higher value, of course, slightly reduces RoHCs > robustness to "continuous" dropped packets. > > Also, Section 4.5.1 in RFC 3095 already alludes to this possiblity. > Specifically, > > d) For field values that are expected to undergo small negative > changes and larger positive changes, such as the RTP TS for video, > or RTP SN when there is misordering, p can be set to 2^(k-2) - 1. > The interval becomes [v_ref - 2^(k-2) + 1, v_ref + 3 * 2^(k-2)], > i.e., 3/4 of the interval is used for positive changes. > > > Can someone please comment on this reordering issue? I dont see much > drawback to setting p to a higher value when the environment has > higher reordering. Was there a reason I am missing that p is set to 1? > Is there any drawback from setting it to a higher value? > > I would appreciate responses. > > Thanks, > Rohit > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 20 08:46:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28570 for ; Wed, 20 Oct 2004 08:46:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG3H-00081J-Dh for rohc-web-archive@ietf.org; Wed, 20 Oct 2004 08:59:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF0j-0007sJ-M1; Wed, 20 Oct 2004 07:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDt2-0002cC-BL for rohc@megatron.ietf.org; Wed, 20 Oct 2004 06:40:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19371 for ; Wed, 20 Oct 2004 06:40:00 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKE56-0005JG-1p for rohc@ietf.org; Wed, 20 Oct 2004 06:52:51 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9KA47RU030408 for ; Wed, 20 Oct 2004 12:04:07 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 12:04:07 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4V8F8R67>; Wed, 20 Oct 2004 12:04:07 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Rohit Kapoor'" , rohc@ietf.org Subject: RE: [rohc] Reordered Packets Date: Wed, 20 Oct 2004 12:03:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 20 Oct 2004 10:04:07.0486 (UTC) FILETIME=[232A2DE0:01C4B68C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Well you have to standardize a value for p, and as in-order-delivery was considered a reasonable assumption when ROHC RTP, p was chosen as it is in RFC 3095. Please see the ROHC-over-reordering draft for discussions about these issues. BR /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Rohit Kapoor > Sent: den 16 oktober 2004 02:19 > To: rohc@ietf.org > Subject: [rohc] Reordered Packets > > > Hi, > > I was wondering what the thinking is regarding enabling RoHC to handle > reordering. > > Not being able to handle reordering is one issue that has been cited > as a drawback of RoHC. My feeling is however, that this is not an > inherent limitation of RoHC but merely an artifact of a parameter > value specified in RFC 3095. Specifically, from section 5.7 of RFC > 3095, > > SN: The compressed RTP Sequence Number. > > Compressed with W-LSB. The interpretation intervals, > see section > 4.5.1, are defined as follows: > > p = 1 if bits(SN) <= 4 > p = 2^(bits(SN)-5) - 1 if bits(SN) > 4 > > p = 1 can handle a reordering of 1. Higher values of p can handle more > reordering. The higher value, of course, slightly reduces RoHCs > robustness to "continuous" dropped packets. > > Also, Section 4.5.1 in RFC 3095 already alludes to this possiblity. > Specifically, > > d) For field values that are expected to undergo small negative > changes and larger positive changes, such as the RTP TS > for video, > or RTP SN when there is misordering, p can be set to > 2^(k-2) - 1. > The interval becomes [v_ref - 2^(k-2) + 1, v_ref + 3 * 2^(k-2)], > i.e., 3/4 of the interval is used for positive changes. > > > Can someone please comment on this reordering issue? I dont see much > drawback to setting p to a higher value when the environment has > higher reordering. Was there a reason I am missing that p is set to 1? > Is there any drawback from setting it to a higher value? > > I would appreciate responses. > > Thanks, > Rohit > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 20 08:52:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29048 for ; Wed, 20 Oct 2004 08:52:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG9C-0008BW-31 for rohc-web-archive@ietf.org; Wed, 20 Oct 2004 09:05:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF43-0008LL-Uc; Wed, 20 Oct 2004 07:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEJr-0006rn-Oc for rohc@megatron.ietf.org; Wed, 20 Oct 2004 07:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21941 for ; Wed, 20 Oct 2004 07:07:43 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKEVw-0005yy-3o for rohc@ietf.org; Wed, 20 Oct 2004 07:20:35 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9KB7TfM016464 for ; Wed, 20 Oct 2004 13:07:29 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 13:07:24 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4V8F9CP8>; Wed, 20 Oct 2004 13:07:24 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Lars-Erik Jonsson (LU/EAB)" , "Ghyslain Pelletier (LU/EAB)" , "'rohc@ietf.org'" Subject: RE: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095 Date: Wed, 20 Oct 2004 13:07:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 20 Oct 2004 11:07:24.0520 (UTC) FILETIME=[FA5F9680:01C4B694] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Ghyslain and others, I've reworked the text, ok? /L-E 8.12. Expecting UOR-2 ACKs in O-mode It should be noted that the use of UOR-2 ACKs in O-mode, as discussed in section 5.4.1.1.2, is indeed optional, so a decompressor can send ACKs for other purposes than actually acking the UOR-2, without then having to continue sending them for all UOR-2. Similarly, compressor implementations can totally ignore UOR-2 ACKs for the purpose of adapting the optimistic approach strategies. Current implementation experience also suggests using that approach, and the recommendation is thus to not make use of the optional ACK mechanism in O-mode, neither in compressor nor in decompressor implementations. For implementers who still want to make use of the optional O-mode acks, the following clarifications should be taken into account. Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in O-mode, and explains a conceptual algorithm for a compressor to determine whether such ACKs can be expected from the decompressor, simply using a condition based on unspecified parameters k_3 and n_3. However, what is not clearly pointed out is the importance of being very careful when implementing this confidence algorithm, as using an incorrect expectation on UOR-2 ACKs as a basis for compressor behavior will significantly degrade the compression performance. If a compressor implementation wants to adapt its optimistic approach behavior on potential UOR-2 ACK usage, the confidence algorithm for determining UOR-2 ACK usage must be carefully designed, with k_3 and n_3 having values much larger than 1, as UOR-2 ACKs can be sent from a decompressor for other purposes than to actually ac! knowledge the UOR-2 packet, e.g. to send feedback data such as clock resolution, or to initiate a mode transfer. Before adapting a compressor to the potential use of UOR-2 ACKs, the implementer must ensure all these aspects are considered by the confidence algorithm. > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Lars-Erik Jonsson (LU/EAB) > Sent: den 13 oktober 2004 13:22 > To: Ghyslain Pelletier (LU/EAB); 'rohc@ietf.org' > Subject: RE: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095 > > > Comments inline... > > > -----Original Message----- > > From: Ghyslain Pelletier (LU/EAB) > > Sent: den 13 oktober 2004 13:16 > > To: Lars-Erik Jonsson (LU/EAB); 'rohc@ietf.org' > > Subject: RE: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095 > > > > > > > > > > 8.12. When to expect UOR-2 ACKs in O-mode > > > > > > Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in > > > O-mode, and explains a conceptual algorithm for a > compressor to > > > determine whether such ACKs can be expected from the > > decompressor, > > > simply using a condition based on unspecified parameters > > > k_3 and n_3. However, what is not clearly pointed out is the > > > importance of being very careful when implementing this > > > confidence algorithm, as using an incorrect expectation on > > > UOR-2 ACKs as a basis for compressor behavior will > significantly > > > degrade the compression performance. If a compressor > > > implementation wants to adapt its optimistic approach behavior > > > on potential UOR-2 ACK usage, the confidence algorithm for > > > determining UOR-2 ACK usage must be carefully designed, with > > > k_3=n_3>>1, as UOR-2 ACKs can be sent from a decompressor for > > > > I think I agree that k_3 and n_3 must be much larger than 1, > > but I think that k_3=n_3>>1 is wrong (i.e. the "k_3=n_3" bit) > > since this essentially means "for a number X of consecutive > > UOR-2". This would also mean that in the presence of packet > > losses (either compressed packets or ACKs), such confidence > > would likely not be achieved very often - if k_3 and n_3 are > > much larger than 1 and the packet loss rate is somewhat high. > > True, k_3 and n_3 is not very useful tools to describe what a > compressor should do to get confidence. I'll rewrite this. > > > > other purposes than to actually acknowledge the UOR-2 packet, > > > e.g. to send feedback data such as clock resolution, or to > > > initiate a mode transfer. Before adapting a compressor to the > > > potential use of UOR-2 ACKs, the implementer must ensure all > > > these aspects are considered in the confidence algorithm. > > > > > > It should again be noted that the use of UOR-2 ACKs in O-mode > > > is indeed optional, so a decompressor can send ACKs for other > > > purposes than actually acking the UOR-2, without then having > > > to continue sending them for all UOR-2. Similarly, compressor > > > implementations can totally ignore UOR-2 ACKs for the purpose > > > of adapting the optimistic approach strategies. > > > > Imo, the above text should be rewritten to provide a stronger > > recommendation to avoid having compressors trying to create > > confidence about acks to UOR-2 and just use the optimistic > > approach as usual. I think this part in itself is a fair > > example of overspecification - would 3095 be rewritten I > > doubt I would like to see that text in. The above suggested > > text should then be moved as the first paragraph of the section. > > That would be fine with me, I agree with your motivation. > > > I think that this section of the implementer's guide (8.12. > > When to expect UOR-2 ACKs in O-mode) should be renamed "8.12. > > Expecting UOR-2 ACKs in O-mode". "When to expect" is still as > > suggestive as 3095 is regarding this. > > True! > > /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Oct 20 09:30:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02106 for ; Wed, 20 Oct 2004 09:30:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGk5-0000YN-SS for rohc-web-archive@ietf.org; Wed, 20 Oct 2004 09:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFmV-000079-J7; Wed, 20 Oct 2004 08:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEzq-0007NY-TC for rohc@megatron.ietf.org; Wed, 20 Oct 2004 07:51:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24858 for ; Wed, 20 Oct 2004 07:51:08 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKFBu-0006x7-El for rohc@ietf.org; Wed, 20 Oct 2004 08:03:59 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9KBopfM026971 for ; Wed, 20 Oct 2004 13:50:51 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 13:50:51 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <4V8F9PZ1>; Wed, 20 Oct 2004 13:50:51 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Ramin Rezaiifar'" Subject: RE: [rohc] I-D ACTION:draft-ietf-rohc-over-reordering-00.txt Date: Wed, 20 Oct 2004 13:50:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-OriginalArrivalTime: 20 Oct 2004 11:50:51.0511 (UTC) FILETIME=[0C42D870:01C4B69B] X-Spam-Score: 1.1 (+) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1382387562==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1382387562== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B69A.F4067214" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B69A.F4067214 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ramin, =20 You are correct - thank you for flagging this error. Values in that column should be 14, 31, 62, 124, 248, 496. ///Ghyslain=20 -----Original Message----- From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of = Ramin Rezaiifar Sent: den 17 oktober 2004 06:46 To: Internet-Drafts@ietf.org Cc: rohc@ietf.org; Lars-Erik Jonsson (LU/EAB); i-d-announce@ietf.org Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-over-reordering-00.txt The values in the 3rd column of the table on page 7 don't seem to be = correct. =20 For example, when k=3D4, (2^k-1)-p is equal to 16-1-1=3D14. The values in the 3rd column are computed as: 2^(k-1)-1 (but I think = it should really be (2^k-1)-p) -Ramin Rezaiifar raminr@qualcomm.com =20 --=20 Ghyslain Pelletier, Dipl. Ing.=20 Wireless IP Optimizations=20 Ericsson Research, Corporate Unit=20 Ericsson AB, Laboratoriegr=E4nd 11=20 Box 920, S-97128 Lule=E5, SWEDEN=20 Phone : +46 (0) 8 404 29 43=20 Mobile: +46 (0) 70 264 83 14=20 Ghyslain.Pelletier@ericsson.com=20 http://www.ericsson.com =20 -----------------------------------=20 The opinions expressed in this=20 message are my personal opinions.=20 These opinions are not=20 necessarily those of my employer,=20 unless stated otherwise.=20 -----------------------------------=20 =20 Internet-Drafts@ietf.org wrote:=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Robust Header Compression Working = Group of the IETF. Title : RObust Header Compression (ROHC): ROHC over=20 Channels that can Reorder Packets Author(s) : G. Pelletier, et al. Filename : draft-ietf-rohc-over-reordering-00.txt Pages : 20 Date : 2004-10-12 =09 RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses = aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-00.t= xt = =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org = with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce = =20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-over-reordering-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html =20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt = =20 Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org . In the body type: "FILE /internet-drafts/draft-ietf-rohc-over-reordering-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 _____ =20 _______________________________________________ Rohc mailing list Rohc@ietf.org =20 https://www1.ietf.org/mailman/listinfo/rohc = =20 =20 ------_=_NextPart_001_01C4B69A.F4067214 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Ramin,
 
You=20 are correct - thank you for flagging this=20 error.
Values=20 in that column should be 14, 31, 62, 124, 248, = 496.

///Ghyslain =


-----Original Message-----
From: = rohc-bounces@ietf.org=20 [mailto:rohc-bounces@ietf.org]On Behalf Of Ramin=20 Rezaiifar
Sent: den 17 oktober 2004 06:46
To:=20 Internet-Drafts@ietf.org
Cc: rohc@ietf.org; Lars-Erik = Jonsson=20 (LU/EAB); i-d-announce@ietf.org
Subject: Re: [rohc] I-D=20 = ACTION:draft-ietf-rohc-over-reordering-00.txt


The values in the 3rd column of the table on page 7 don't seem = to be=20 correct. 
For example, when k=3D4, (2^k-1)-p is equal to=20 16-1-1=3D14.
The values in the 3rd column are computed as: = 2^(k-1)-1  (but=20 I think it should really be (2^k-1)-p)

-Ramin Rezaiifar
raminr@qualcomm.com

--
 Ghyslain Pelletier, Dipl. Ing.
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, = Laboratoriegr=E4nd 11=20
 Box 920, S-97128 Lule=E5, = SWEDEN=20
 Phone : +46 (0)  8 = 404 29=20 43
 Mobile: +46 (0) = 70 264 83=20 14
 Ghyslain.Pelletier@ericsson.com
 http://www.ericsson.com

-----------------------------------=20
 The opinions expressed in = this=20
 message are my personal=20 opinions.
 These = opinions are=20 not
 necessarily = those of my=20 employer,
 unless = stated=20 otherwise.
-----------------------------------

  
Internet-Drafts@ietf.org = wrote:=20 
A New Internet-Draft is available from the =
on-line Internet-Drafts directories.
This draft is a work item of the Robust Header Compression Working =
Group of the IETF.

	Title		: RObust Header Compression (ROHC): ROHC over=20
			  Channels that can Reorder Packets
	Author(s)	: G. Pelletier, et al.
	Filename	: draft-ietf-rohc-over-reordering-00.txt
	Pages		: 20
	Date		: 2004-10-12
=09
RObust Header Compression (ROHC), RFC 3095, defines a framework for
   header compression, along with a number of compression protocols
   (profiles). One operating assumption for the profiles defined in RFC
   3095 is that the channel between compressor and decompressor is
   required to maintain packet ordering. This document discusses =
aspects
   of using ROHC over channels that can reorder packets. It provides
   guidelines on how to implement existing profiles over such channels,
   as well as suggestions for the design of new profiles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reo=
rdering-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.=
org with the word unsubscribe in the body of the message. =20
You can also visit https://www=
1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the =
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rohc-over-reordering-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=
=20
or ftp://ftp.ietf.org/ie=
tf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-over-reordering-00.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/rohc

------_=_NextPart_001_01C4B69A.F4067214-- --===============1382387562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1382387562==-- From rohc-bounces@ietf.org Thu Oct 21 08:16:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13424 for ; Thu, 21 Oct 2004 08:16:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKc4U-0007SM-JF for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 08:29:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKavs-0003Qq-Ut; Thu, 21 Oct 2004 07:16:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKOhU-00019Q-3e for rohc@megatron.ietf.org; Wed, 20 Oct 2004 18:12:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04034 for ; Wed, 20 Oct 2004 18:12:47 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKOtr-0007gg-ER for rohc@ietf.org; Wed, 20 Oct 2004 18:25:45 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9KMCasL077020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2004 17:12:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4176E2D4.50504@nostrum.com> Date: Wed, 20 Oct 2004 17:12:36 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Surtees, Abigail" Subject: Re: FW: [rohc] NACK draft comments References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: "Adam Roach \(E-mail\)" , "Carsten Bormann \(E-mail\)" , "'rohc@ietf.org'" , "'Lars-Erik Jonsson \(LU/EAB\)'" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit So, I'm finally getting around to updating the NACK draft based on last call comments. Actions detailed inline. Surtees, Abigail wrote: >Suggested text: > >" When a NACK is received for a message sent over a reliable transport, > the SigComp layer must indicate to the application that an error has > occurred. In general, the application should react in the same way > as it does for any other transport layer error, such as a TCP > connection reset. For most applications, this reaction will > initially be an attempt to reset/re-establish the connection, and re- > initiate the failed transaction. The SigComp layer should also use the > information contained in the NACK to make appropriate adjustments to the > compressor associated with the proper compartment (similar to the >adjustments > made for unreliable transport). Thus if the compartment is not reset by > resetting the TCP connection, the next message will take advantage of the > > adjustments." > > Sounds like a reasonable approach. I've updated the text as you've suggested. >Other minor comments: > >Page 8 section 3.1 >'Although the format of NACK messages are the same as the second variant of >normal SigComp messages, it is useful to demonstrate the specific fields as >they appear inside the "returned feedback item" field.' > >I think this is a relic of the NACK having once been the returned feedback >item. >This sentence is not in line with either the text preceding it or the format >of the NACK shown. > >Suggested text: >"The format of the NACK message and the use of the fields within it are >shown in Figure 1." > > Done. >Page 12 number 21. ID_NOT_UNIQUE >This section doesn't mention the details that go with this reason code >(which are shown in Fig 2). > >Page 13 number 23. STATE_TOO_SHORT >This section doesn't mention the details that go with this reason code >(which are shown in Fig 2). > > > Fixed. >[Very minor: >Page 14, 4.2 '... NACK message ...' is misssing an s.] > > Fixed. Thanks! /a _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 08:18:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13737 for ; Thu, 21 Oct 2004 08:18:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKc6o-0007XT-SU for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 08:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKaxS-0006dO-FS; Thu, 21 Oct 2004 07:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKPX7-0006if-67 for rohc@megatron.ietf.org; Wed, 20 Oct 2004 19:06:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11111 for ; Wed, 20 Oct 2004 19:06:13 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKPjb-000198-CF for rohc@ietf.org; Wed, 20 Oct 2004 19:19:12 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9KN6B5l081373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2004 18:06:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4176EF62.4010707@nostrum.com> Date: Wed, 20 Oct 2004 18:06:10 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert.Sugar@nokia.com Subject: Re: [rohc] NACK draft comments References: <21B200DF0688CC45ACF38F49D2279832013397E9@buebe002.europe.nokia.com> In-Reply-To: <21B200DF0688CC45ACF38F49D2279832013397E9@buebe002.europe.nokia.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Robert.Sugar@nokia.com wrote: >---------- >Section 2.2: > "For a connectionless transport, such as UDP, the NACK message is sent > back to the originator of the failed message at the port and IP > address from which the message was sent. >... > > The behavior specified above is strictly necessary for any > generally useful form of a NACK mechanism. In the most general > case, when an implementation receives a message that it cannot > decompress, it has exactly three useful pieces of information: the > contents of the message, an indication of why the message cannot > be decoded, and the IP address and port from which the message > originated. Note that none of these contains any indication of > where the remote application is listening for messages, if it > differs from the sending port." > >This is true for the general case, but could be different in special cases. For example SIP uses the registration procedure, where the registrar may tell from the IP address where the user's listening port is. In that case it'd make more sense to send the NACK to the listening port. > The problem with allowing such an approach is that it falls apart except in the most narrowly constrained cases. Consider the situation in which a SIP registrar has a registration that binds the AOR "sip:adam@nostrum.com" to the contact "sip:adam@adsl-209-30-28-247.dsl.rcsntx.swbell.net:5060" and the AOR "sip:not-adam@example.com" to the contact "sip:not-adam@adsl-209-30-28-247.dsl.rcsntx.swbell.net:5070." Now, that registrar sees a SigComp UDP packet arrive from port 62047 of the IP address 209.30.28.247. (I'm making the assumption that you can map that 209.30.28.247 back to the appropriate contacts, which can be a bit of a feat in itself, but we'll leave that alone for now). The message fails to decompress. It wants to send a NACK in response to it. Where does it go? The answer is: you don't know. It might be from the client running on port 5060. It might be from the client running on port 5070. These clients might be for completely different users (e.g. they're going to a server with several X clients hanging off of it), and they're almost certainly different applications. How do you collect enough information to decide whether to send the NACK to 5060 or to 5070? You can't. That's precisely why we ended up making the NACK go back to the port from which it came. There's really no other way this can be made to work. >Section 2.3.2: > "When a NACK is received for a message sent over a reliable transport, > the SigComp layer must indicate to the application that an error has > occurred. In general, the application should react in the same way > as it does for any other transport layer error, such as a TCP > connection reset. For most applications, this reaction will > initially be an attempt to reestablish the connection, and re- > initiate the failed transaction." > >Why should the SigComp layer always contact the application? If it acts as a shim layer couldn't it just silently retransmit the message with different parameters (just as TCP behaves on packet losses). It should only contact to the application, when there are unrecoverable errors (such as multiple NACKs after several attempts or TCP connection failure). And in particular it should be avoided that the application resets and reestablishes the TCP connection just because of a single NACK, for it is a rather time consuming procedure in large-delay networks. > > The original versions of the draft contained such language. It was changed after someone -- in fact, looking through the archives, you -- suggested that this behavior was untenable. To quote you (message dated 10/30/2002): > Problem: > Endpoints have to store SHA-1 hash and - in case of reliable transport > - the uncompressed version of ALL messages sent out. This is hardly > acceptable from the memory point of view on both sides. Moreover the > draft does not define when to release this data, since we have no ACK. > > Possible solution: > Allow endpoints to handle just a set of error codes (which are not > message specific). Thus it does not have to store anything, but is > still able to react to STATE_NOT_FOUND for example. The other errors > could trigger some default actions (like RESET). However, we lose the > retransmission possibilities in case of TCP this way. You asked me to fix this, and I did. I'm not going to go back to the original behavior -- the one you called a problem two years ago -- this far into the process. /a _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 08:23:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14245 for ; Thu, 21 Oct 2004 08:23:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcBL-0007gL-KR for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 08:36:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKazO-00030q-P5; Thu, 21 Oct 2004 07:20:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKQ40-0000BZ-F3 for rohc@megatron.ietf.org; Wed, 20 Oct 2004 19:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18501 for ; Wed, 20 Oct 2004 19:40:07 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKQGQ-00033z-EN for rohc@ietf.org; Wed, 20 Oct 2004 19:53:07 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9KNe5xH084009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2004 18:40:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4176F754.6050302@nostrum.com> Date: Wed, 20 Oct 2004 18:40:04 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Price Subject: Re: [rohc] Review of SigComp NACK draft References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Richard Price wrote: > Open issue in Section 2.4: In general it would be a good idea to > explicitly signal support for NACKs, rather than attempting to probe > the remote endpoint by sending dodgy SigComp messages, as the latter > approach could lead to all sorts of problems. However, why not > indicate support for NACKs by assigning a new SigComp version number > (i.e. SigComp Version 0x02 = SigComp Version 0x01 + NACKs)? Seems more > straightforward than relying on the decompressor bytecode to detect > NACK support and then signal this to the remote endpoint as requested > feedback. Thanks for spotting the open issue! I had completely forgotten this was in here. I really like the simplicity and speed of detection that your suggestion provides. I've incorporated it into the draft. > Section 2: Typo - "The actual format and values are described in > section Section 3." Fixed. > Section 2.1: It might be worth noting that the information used to > determine which SigComp message belongs to which compartment is not > always carried in the SigComp message itself. In "continuous mode" for > example, we make the assumption that the lower layer provides enough > security to map SigComp messages to their correct compartment. The > contents of the SigComp message are irrelevant to finding the correct > compartment in this case. In fact, there is not always enough > information in the SigComp message itself to determine the compartment > to which it belongs. I understand and agree with everything you just said. I'm not entirely sure how it relates to section 2.1. All section 2.1 says is (paraphrased), "store the SHA1 hash such that, if someone hands it back to you, you can find the correct compartment to apply it to." It doesn't assume that the message itself contains information about the compartment -- only that the SigComp compressor has some idea which compartment it's currently working with (which always must be true). Obviously, there's something unclear about this section. I've added the following clarifying text: In other words, if someone hands the SHA-1 hash back to the compressor, it needs to be able to find the compartment with which it was working when it sent the message with that hash. This only requires that the compressor knows with which compartment it is working when it sends a message (which is always the case), and that the SHA-1 hash, when stored, points to that compartment in some way. > > Section 2.2: Typo - "See section Section 3 for more information about > formatting the NACK message and its fields." > Fixed. > Section 3.1: The phrase "it is useful to demonstrate the specific > fields as they appear inside the "returned feedback item" field" might > be left over from a previous version of the draft. > Thanks. I've fixed this. > Section 3.1: Typo - "The specific codes are given in section Section 3.2" > Fixed. > Section 3.1: Might be worth pointing out that the term "program > counter" is using the standard hardware definition of a program > counter, and thus is the UDVM memory address of the failed UDVM > instruction. > Ah, yes. I didn't realize that 3320 never talks about the program counter. I've clarified: "PC of failed instruction" is a two-byte field containing the value of the program counter when failure occurred (i.e. the memory address of the failed UDVM instruction). > Section 3.1: Typo - "See section Section 3.2 for specific information > on what appears in this field." > Fixed. > Section 3.2: Typo - "A state that was referenced (either using > STATE-ACCESS instruction or in the actual SigComp message itself)" I'm not certain what you believe the typo here is. Is it just that the phrase is a bit awkward? I've attempted to make it clearer: 1. STATE_NOT_FOUND A state that was referenced cannot be found. The state may have been referenced by the UDVM executing a STATE-ACCESS instruction; it also may have been referenced by the "partial state identifier" field in a SigComp message. The "details" field contains the state identifier for the state that could not be found. This is also the proper error to return in the case that a unique state item was matched but fewer bytes of state ID were sent than required by the minimum_access_length. Thanks again for your comments. I'll be dropping a -02 version of the document shortly. /a _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 08:26:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14756 for ; Thu, 21 Oct 2004 08:26:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcEE-0007ov-TW for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 08:39:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb2m-0003zi-1B; Thu, 21 Oct 2004 07:23:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKRFI-00056W-Dx for rohc@megatron.ietf.org; Wed, 20 Oct 2004 20:56:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28863 for ; Wed, 20 Oct 2004 20:55:53 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKRRj-0006cY-7k for rohc@ietf.org; Wed, 20 Oct 2004 21:08:51 -0400 Received: from [192.168.0.111] (adsl-209-30-28-252.dsl.rcsntx.swbell.net [209.30.28.252]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i9L0tpH9090245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Oct 2004 19:55:53 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <41770916.2090401@nostrum.com> Date: Wed, 20 Oct 2004 19:55:50 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [rohc] New Version of SigComp NACK draft X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit I have just submitted a new (and hopefully final) version of the SigComp NACK draft. This version incorporates the comments that were received during and since the last call period. No open issues remain, and I believe the document is ready to be sent to the IESG for consideration of publication. Interested parties are encouraged to review the document and ensure that they agree with my assessment. Until it appears in the archives, you can retrieve a copy from: http://www.nostrum.com/~adam/ids/draft-ietf-rohc-sigcomp-nack-02.txt http://www.nostrum.com/~adam/ids/draft-ietf-rohc-sigcomp-nack-02.html /a _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 09:17:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26034 for ; Thu, 21 Oct 2004 09:17:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKd1V-0002A5-72 for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 09:30:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcDe-0007BF-9i; Thu, 21 Oct 2004 08:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbJA-0008U4-H1 for rohc@megatron.ietf.org; Thu, 21 Oct 2004 07:40:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05744 for ; Thu, 21 Oct 2004 07:40:38 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbVk-0005Pr-La for rohc@ietf.org; Thu, 21 Oct 2004 07:53:41 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9LAdYLh030354 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Oct 2004 12:39:35 +0200 Message-ID: <4177A042.7060304@effnet.com> Date: Thu, 21 Oct 2004 13:40:50 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann , Eilert Brinkmann , "Finking, Robert" , "West, Mark" , Lars-Erik Jonsson , Ghyslain Pelletier Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org Subject: [rohc] ROHC-FN: Changing the behavior of the "let" encoding method X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Hi! Here's a proposal for another change to the ROHC-FN to make it more clear to users. The last WIP draft has defined let as: 4.6 Let The reserved keyword "let" takes a boolean expression as a parameter. It can be used to assert that the expression has a specific value, in order to choose a particular packet format from a list of possible formats: let () When the boolean expression evaluates to false, the environment of the expression fails, i.e. does not succeed. What seems unclear is "the environment of the expression fails". What is "the environment"? I guess it's intention is to say that anything in the same scope as this let-statement fails. We suggest that "let" be allowed to provide its own scope: Examples of such use: uncompressed_format = version, src, dst, let (version == 4) { ip_id, df, }, let (version == 6) { flow_label, }, .... As can be seen, this would form the uncompressed_format for co_baseheader (innermost IP header and TCP header). The above would be useful for example to solve the definition of the uncompressed format for a protocol that has multiple versions (i.e. IPv4/v6) Another example: static_or_irreg32(flag) === { uncompressed_format = field; %[ 32 ] let (flag == 1) { format_irreg = field, %[ 32 ] { field ::= irregular(32); } }; let (flag == 0) { format_static = field, %[ 0 ] { field ::= static; } }; }; Example 3: dummy_enc(flag) === { uncompressed_format = field1, field2; format_fluffy = { let(flag == 0) field1 ::= irregular(16); let(flag == 1) field1 ::= static; field2 ::= irregular(912); } } So, by using enclosing braces, the "let" can provide its own scope. When not using braces, the let is scoped only to the statement it is a part of. This modification will be an improvement for the following reasons: - Allows "let" to provide its own scope, which means that less FN has to be written: * Example 3 would have to have two different format_ definitions with the "old" let encoding. - Allows "let" to be used in uncompressed_format and default_methods section of the FN * Example 1 would require that both the uncompressed format for IPv4 and IPv6 be written separately. In the latest packet formats on the cvs repository, the packet format simply try to avoid spelling out the IP fields but it seems wrong. With this modification to "let", it is possible to still do it in a somewhat concise manner. - Example 2 allows the let to be used just like an if statement, with a clear scope. - Makes the definition unambiguous, since let provides a scope instead of having to interpret what the "environment" is. Also, with the old definition, statements appearing in the same scope, but before the let would also fail, which seems akward at best and more difficult to realize. BR, Kristofer Sandlund, Effnet AB Ghyslain Pelletier, Ericsson _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 09:21:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26697 for ; Thu, 21 Oct 2004 09:21:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKd5T-0002MR-QJ for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 09:34:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcaK-0007aN-4v; Thu, 21 Oct 2004 09:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbTR-0007tq-Ts for rohc@megatron.ietf.org; Thu, 21 Oct 2004 07:51:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07573 for ; Thu, 21 Oct 2004 07:51:16 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbg3-00065d-Iy for rohc@ietf.org; Thu, 21 Oct 2004 08:04:20 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9LAoJLh030381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Oct 2004 12:50:19 +0200 Message-ID: <4177A2C6.90209@effnet.com> Date: Thu, 21 Oct 2004 13:51:34 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann , Eilert Brinkmann , "Finking, Robert" , "West, Mark" , Lars-Erik Jonsson , Ghyslain Pelletier , rohc@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Subject: [rohc] ROHC-FN & ROHC-TCP: Control fields X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Hi! Me and Ghyslain are trying to fix the final nits in the TCP packet formats, and with all the changes that the FN has undergone, it seems like the notion of control fields does not seem to be fully defined in the current WIP draft. Basically, we have two types of control fields: those that need to be stored in context (e.g. MSN, IP-ID behavior, ecn_used, etc), and those that are just "compressed_value" (e.g. discriminators). Those that update context are currently "defined" in default_methods or in the compressed format, which seems a bit weak, so we suggest that we add a "control_fields" section to encoding methods so that it is possible for the user to actually see which fields that need context. So, we might have: some_enc === { uncompressed_format = field1, field2; control_fields = msn; format_1 = discriminator, field1, msn, { discriminator ::= '100' field1 ::= irregular(16); msn ::= irregular(16); } } With this syntax, it is clear which fields that are defined in this structure that sets context, which we don't think the old syntax does very well. ****************** Now, over to how to use control fields in the TCP draft. Some control fields need to be known outside the scope of their definition, e.g. the ecn_used control field defined in the tcp header controls the presence of TOS bits in some compressed packets. So an example of the "problem" (using the syntax suggested above): tcp === { uncompressed_format = ack_flag, ...... control_fields = ecn_used, msn; format_tcp_dynamic = ecn_used, %[ 1 ] ack_flag, %[ 1 ] urg_flag, %[ 1 ] psh_flag, %[ 1 ] ...... } co_baseheader === { uncompressed_format = control_fields = ecn_used, msn, ipid_behavior; % IPID behavior in innermost IP format_xxx..... } ipv4 === { ...... format_ipv4_outer_irregular = ip_id, tos_tc, ip_ecn_flags, { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg (ip_id_behavior); tos_tc ::= irreg_tos_tc (ecn_used); <---------- ip_ecn_flags ::= ip_irreg_ecn (ecn_used); <---------- }; } The "ecn_used" context control field is something that is used both in TCP and in the base header (quite natural since the base header is an IP + a TCP header), and it is referenced in the IPv4 structure. Clearly, the ecn_used in the ipv4 structure needs some way to make a reference to something that is defined outside of its own scope. Questions: 1) How is the user supposed to know that the ecn_used in the base header should be the same field that was established by the dynamic chain in the TCP header? 2) How should the IPv4 structure refer to this field since it is outside its own scope? An answer to the second question might be to define a "global" constant (constants are defined in 4.2 of the latest WIP FN) that gets a new value when the ecn_used context value is changed, i.e. something along the lines of: ECN_USED = 0; co_baseheader === { uncompressed_format = control_fields = ecn_used, msn, ipid_behavior; % IPID behavior in innermost IP format_xxx = ecn_used, blah, { ecn_used ::= some_encoding(); let (ECN_USED == ecn_used:uncomp_value); blah ::= some_other_encoding; } } ipv4 === { ...... format_ipv4_outer_irregular = ip_id, tos_tc, ip_ecn_flags, { ip_id_behavior ::= static; ip_id ::= ip_id_enc_irreg (ip_id_behavior); tos_tc ::= irreg_tos_tc (ECN_USED); ip_ecn_flags ::= ip_irreg_ecn (ECN_USED); }; } I have no idea if this is actually legal with the FN, but it seems good enough, so I'm are going to put this into the packet formats for now, but it can always be changed to something else if there is disagreement. BR, Kristofer Sandlund, Effnet AB Ghyslain Pelletier, Ericsson _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 10:23:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04707 for ; Thu, 21 Oct 2004 10:23:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe35-0004DV-1K for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 10:36:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdiN-0004iS-2v; Thu, 21 Oct 2004 10:14:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKW36-0005kQ-IU for rohc@megatron.ietf.org; Thu, 21 Oct 2004 02:03:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01088 for ; Thu, 21 Oct 2004 02:03:37 -0400 (EDT) Received: from eng.ie.cuhk.edu.hk ([137.189.96.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKWFZ-00075P-HA for rohc@ietf.org; Thu, 21 Oct 2004 02:16:38 -0400 Received: from viruswall2.ie.cuhk.edu.hk (viruswall2 [137.189.96.53]) by eng.ie.cuhk.edu.hk (8.12.10/8.12.10) with ESMTP id i9L63aJW023532 for ; Thu, 21 Oct 2004 14:03:36 +0800 (HKT) Received: from 825pc13 (iegatea1.ie.cuhk.edu.hk [137.189.98.1]) by viruswall2.ie.cuhk.edu.hk (8.12.10/8.12.10) with ESMTP id i9L63Zs4027977 for ; Thu, 21 Oct 2004 14:03:35 +0800 From: "Tan Wee Lum" To: Date: Thu, 21 Oct 2004 14:03:49 +0800 Message-ID: <000501c4b733$bbbb83e0$443aa8c0@825pc13> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Oct 2004 10:14:50 -0400 Subject: [rohc] Feedback channels in ROHC-TCP X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Hi, In the ROHC-TCP draft version 7, it is mentioned in Section 3.1 that the disadvantage of the full header request mechanism in IPHC is that it requires a feedback channel that may be unavailable in some circumstances. I am wondering what are the circumstances in which a feedback channel is not available? I thought that a TCP connection would require a full-duplex channel to work? Thanks for any clarification. Wee Lum _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 10:24:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04866 for ; Thu, 21 Oct 2004 10:24:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe4A-0004Fa-Eg for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 10:37:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdkE-0005bs-2D; Thu, 21 Oct 2004 10:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdZd-0002CU-Hw for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01415 for ; Thu, 21 Oct 2004 10:05:47 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdmG-0003du-0c for rohc@ietf.org; Thu, 21 Oct 2004 10:18:52 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9LE5NMG017416; Thu, 21 Oct 2004 16:05:24 +0200 (MEST) In-Reply-To: <4177A042.7060304@effnet.com> References: <4177A042.7060304@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3FA40876-236A-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding method Date: Thu, 21 Oct 2004 16:05:22 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , Carsten Bormann , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit > Here's a proposal for another change to the ROHC-FN to make it more > clear to users. The last WIP draft has defined let as: I'm not sure I want to change much at the current stage. The notation seems to be expressive enough as it is, and already hard to "implement" (i.e., to write a checker or an execution engine for). Last but not least, it is already somewhat hard to understand. Adding concepts will not improve that situation. > What seems unclear is "the environment of the expression fails". What > is "the environment"? The packet format that the let is in (explicitly, or implicitly via default_methods). Note that there is no way to "take back" a "let" that comes in via default_methods, which is a bit of a missing feature. (Which I don't want to tackle at this stage -- you can always repeat the let in all other formats). > uncompressed_format = version, > src, > dst, > let (version == 4) { > ip_id, > df, > }, > let (version == 6) { > flow_label, > }, > .... > As can be seen, this would form the uncompressed_format for > co_baseheader (innermost IP header and TCP header). So, for version == 5, neither ip_id nor flow_label would be there? Also, I'm not sure the example works very well because the whole format changes between 4 and 6; the existing spec solves this rather nicely (and compactly). > The above would be useful for example to solve the definition of the > uncompressed format for a protocol that has multiple versions (i.e. > IPv4/v6) > > Another example: > > static_or_irreg32(flag) === > { > uncompressed_format = field; %[ 32 ] > > let (flag == 1) { > format_irreg = field, %[ 32 ] > { > field ::= irregular(32); > } > }; > let (flag == 0) { > format_static = field, %[ 0 ] > { > field ::= static; > } > }; > }; This can be expresser shorter using the existing means. > Example 3: > > dummy_enc(flag) === > { > uncompressed_format = field1, > field2; > format_fluffy = > { > let(flag == 0) field1 ::= irregular(16); > let(flag == 1) field1 ::= static; > field2 ::= irregular(912); > } > } If I wanted to do this, I'd write: > Example 3: > > dummy_enc(flag) === > { > uncompressed_format = field1, > field2; > format_fluffy = > { > { let(flag == 0); > field1 ::= irregular(16); } > { let(flag == 1); > field1 ::= static; } > field2 ::= irregular(912); > } > } But then, I don't really want to. Right now, the right way to do this is: fluff1(flag) === { uncompressed_format = f1; co_1 = { let(flag == 0); f1 ::= irregular(16); } co_2 = { let(flag == 1); f1 ::= static; } } dummy_enc(flag) === { uncompressed_format = field1, field2; format_fluffy = { field1 ::= fluff1(flag); field2 ::= irregular(912); } } More verbose, yes; but (given reasonable names that suggest an abstraction like "optional32") even more readable. (Note that these abstractions are often reusable in more than one place.) > * Example 3 would have to have two different format_ definitions > with the "old" let encoding. Yes, see above. > - Makes the definition unambiguous, since let provides a scope instead > of having to interpret what the "environment" is. See above. > Also, with the old definition, statements appearing in the same scope, > but before the let would also fail, which seems akward at best and > more difficult to realize. I don't think we need the concept of "statements", only encoding methods and formats, so I don't think that is a problem. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 10:34:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06640 for ; Thu, 21 Oct 2004 10:34:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeDp-0004Z5-0h for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 10:47:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKduz-0004Wi-Ke; Thu, 21 Oct 2004 10:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdkq-0005lc-Tx for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:17:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03780 for ; Thu, 21 Oct 2004 10:17:22 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdxU-00044E-2w for rohc@ietf.org; Thu, 21 Oct 2004 10:30:28 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9LEHAvn023894; Thu, 21 Oct 2004 16:17:11 +0200 (MEST) In-Reply-To: <4177A2C6.90209@effnet.com> References: <4177A2C6.90209@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] ROHC-FN & ROHC-TCP: Control fields Date: Thu, 21 Oct 2004 16:17:08 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , Carsten Bormann , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit On Oct 21 2004, at 13:51 Uhr, Kristofer Sandlund wrote: > Hi! > > Me and Ghyslain are trying to fix the final nits in the TCP packet > formats, and with all the changes that the FN has undergone, it seems > like the notion of control fields does not seem to be fully defined in > the current WIP draft. > > Basically, we have two types of control fields: those that need to be > stored in context (e.g. MSN, IP-ID behavior, ecn_used, etc), and those > that are just "compressed_value" (e.g. discriminators). The problem is that FN currently does not say anything about the context. > Those that update context are currently "defined" in default_methods > or in the compressed format, which seems a bit weak, so we suggest > that we add a "control_fields" section to encoding methods so that it > is possible for the user to actually see which fields that need > context. That is an interesting proposal. I would feel better if we could flesh out more of the context side of the FN (as opposed to the uncompressed and the compressed side); once we start to really understand this, we might want to have more (or different) ways of saying this. > With this syntax, it is clear which fields that are defined in this > structure that sets context, which we don't think the old syntax does > very well. How about an annotation? > ****************** > Now, over to how to use control fields in the TCP draft. > Some control fields need to be known outside the scope of their > definition, e.g. the ecn_used control field defined in the tcp header > controls the presence of TOS bits in some compressed packets. Now it gets interesting -- but you are not talking about the context (in the sense of inter-packet memory), but you want to link different parts of the spec using the same concept. Right now, we only have encoding method parameters for this purpose, and (having done some work on 3095-FN) I know that this can get rather long in the tooth. It is doable, though. In your example, are you using ecn_used as a field name or as a number? I'm seeing both, which is confusing. > 1) How is the user supposed to know that the ecn_used in the base > header should be the same field that was established by the dynamic > chain in the TCP header? You would have to use a parameter. > 2) How should the IPv4 structure refer to this field since it is > outside its own scope? Ditto. > An answer to the second question might be to define a "global" constant Well, I'd try not to mingle this with constants (which are, kind of, constant). > let (ECN_USED == ecn_used:uncomp_value); This looks like a "global parameter", i.e. an implicit parameter of *every* encoding method that is handed down to *every other* encoding method. Again, this *can* be done using existing notation; however, if you have too many of these parameters, the parameter lists do get rather long (which you can see in 3095-FN). Maybe Eilert can produce an example (I'm off to other things right now, unfortunately). Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 10:42:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07925 for ; Thu, 21 Oct 2004 10:42:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeM1-0004on-33 for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 10:55:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe11-0008G8-PR; Thu, 21 Oct 2004 10:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdr8-00026R-Ba for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:23:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04796 for ; Thu, 21 Oct 2004 10:23:51 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe3k-0004Di-LS for rohc@ietf.org; Thu, 21 Oct 2004 10:36:57 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9LDMjLh030896 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Oct 2004 15:22:45 +0200 Message-ID: <4177C682.7020902@effnet.com> Date: Thu, 21 Oct 2004 16:24:02 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding method References: <4177A042.7060304@effnet.com> <3FA40876-236A-11D9-8CDC-000A95DC4DB6@tzi.org> In-Reply-To: <3FA40876-236A-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit I have to disagree with you. The "base header" can either be (IPv4 + TCP) or (IPv6 + TCP) and we have ~20 different compressed formats for base headers, where the non-sequential packets are common for both. With the old syntax, we'd have to define all those 10-something packets twice, since you cannot put a "let" in uncompressed_format or default_methods. More comments inline. Carsten Bormann wrote: >> Here's a proposal for another change to the ROHC-FN to make it more >> clear to users. The last WIP draft has defined let as: > > > I'm not sure I want to change much at the current stage. Agree, but we have to make this work. So far we've had lots of different versions that "ignores some tricky details", and there's been no input form anyone to solve this, so we had to take some form of path to solve this. > The notation seems to be expressive enough as it is, and already hard to > "implement" (i.e., to write a checker or an execution engine for). Yes, but then again the checker is not a part of the requirements for this, but that it works definitely is :) > Last but not least, it is already somewhat hard to understand. > Adding concepts will not improve that situation. I belive it will. The current concept is hard to understand. > >> What seems unclear is "the environment of the expression fails". What >> is "the environment"? > > > The packet format that the let is in (explicitly, or implicitly via > default_methods). > Note that there is no way to "take back" a "let" that comes in via > default_methods, which is a bit of a missing feature. > (Which I don't want to tackle at this stage -- you can always repeat the > let in all other formats). > >> uncompressed_format = version, >> src, >> dst, >> let (version == 4) { >> ip_id, >> df, >> }, >> let (version == 6) { >> flow_label, >> }, >> .... >> As can be seen, this would form the uncompressed_format for >> co_baseheader (innermost IP header and TCP header). > > > So, for version == 5, neither ip_id nor flow_label would be there? > Also, I'm not sure the example works very well because the whole format > changes between 4 and 6; the existing spec solves this rather nicely > (and compactly) Nope. It does not. In the last version of the packet formats, I tried something with the ip_hdr structures, but Eilert added a FIXME since the fields did not appear explicitly in the uncompresed_format. And earlier versions just ignored IPv6 completely in the base headers, so those did not solve anything. . > >> The above would be useful for example to solve the definition of the >> uncompressed format for a protocol that has multiple versions (i.e. >> IPv4/v6) >> >> Another example: >> >> static_or_irreg32(flag) === >> { >> uncompressed_format = field; %[ 32 ] >> >> let (flag == 1) { >> format_irreg = field, %[ 32 ] >> { >> field ::= irregular(32); >> } >> }; >> let (flag == 0) { >> format_static = field, %[ 0 ] >> { >> field ::= static; >> } >> }; >> }; > > > This can be expresser shorter using the existing means. > >> Example 3: >> >> dummy_enc(flag) === >> { >> uncompressed_format = field1, >> field2; >> format_fluffy = >> { >> let(flag == 0) field1 ::= irregular(16); >> let(flag == 1) field1 ::= static; >> field2 ::= irregular(912); >> } >> } > > > If I wanted to do this, I'd write: > >> Example 3: >> >> dummy_enc(flag) === >> { >> uncompressed_format = field1, >> field2; >> format_fluffy = >> { >> { let(flag == 0); >> field1 ::= irregular(16); } >> { let(flag == 1); >> field1 ::= static; } >> field2 ::= irregular(912); >> } >> } > > > But then, I don't really want to. > Right now, the right way to do this is: > > fluff1(flag) === { > uncompressed_format = f1; > co_1 = { > let(flag == 0); > f1 ::= irregular(16); > } > co_2 = { > let(flag == 1); > f1 ::= static; > } > } > > dummy_enc(flag) === > { > uncompressed_format = field1, > field2; > format_fluffy = > { > field1 ::= fluff1(flag); > field2 ::= irregular(912); > } > } > > More verbose, yes; but (given reasonable names that suggest an > abstraction like "optional32") even more readable. > (Note that these abstractions are often reusable in more than one place.) > Again, no agreement from me. The definition of "let" is ambiguous in its use of "environment", so that would have to be redefined anyway. >> * Example 3 would have to have two different format_ definitions >> with the "old" let encoding. > > > Yes, see above. Having to define ~10 compressed headers twice would be a source for errors, and a reader will see this and say "wow, 30 packet formats! I don't like this". If we're forced to define the same things twice, then the FN is lacking. > >> - Makes the definition unambiguous, since let provides a scope instead >> of having to interpret what the "environment" is. > > > See above. > >> Also, with the old definition, statements appearing in the same scope, >> but before the let would also fail, which seems akward at best and >> more difficult to realize. > > > I don't think we need the concept of "statements", only encoding methods > and formats, so I don't think that is a problem. > Whatever we call it. By statement I meant "one line of FN definition" but I still consider it an ambiguity to see "let" in the middle of a format that makes the previous lines fail. /Kristofer > Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 10:51:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09196 for ; Thu, 21 Oct 2004 10:51:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeUc-00053b-BS for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 11:04:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe8F-0001l8-4g; Thu, 21 Oct 2004 10:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdw3-00057R-5P for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:28:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05684 for ; Thu, 21 Oct 2004 10:28:56 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe8V-0004OK-8w for rohc@ietf.org; Thu, 21 Oct 2004 10:42:02 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9LESkWR008213 for ; Thu, 21 Oct 2004 16:28:46 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 16:28:48 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Oct 2004 16:28:40 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Tan Wee Lum'" , rohc@ietf.org Subject: RE: [rohc] Feedback channels in ROHC-TCP Date: Thu, 21 Oct 2004 16:28:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 21 Oct 2004 14:28:48.0092 (UTC) FILETIME=[472819C0:01C4B77A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa The forward and return flows of a TCP connection might not go over the same path, and only one of the two might thus go over a link where HC is applied (which might be a unidirectional link). E2E, there is of course a bidirectional connection for TCP, but HC is applied on a per-link basis. Rgds, /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Tan Wee Lum > Sent: den 21 oktober 2004 08:04 > To: rohc@ietf.org > Subject: [rohc] Feedback channels in ROHC-TCP > > > Hi, > > In the ROHC-TCP draft version 7, it is mentioned in Section 3.1 that > the disadvantage of the full header request mechanism in IPHC > is that it requires a feedback channel that may be unavailable in > some circumstances. > > I am wondering what are the circumstances in which a feedback channel > is not available? I thought that a TCP connection would require a > full-duplex > channel to work? > > Thanks for any clarification. > > Wee Lum > > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 10:56:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09826 for ; Thu, 21 Oct 2004 10:56:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeZ2-0005CU-Lg for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 11:09:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe9M-0002D7-N4; Thu, 21 Oct 2004 10:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe0b-0008Cg-Qt for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:33:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06450 for ; Thu, 21 Oct 2004 10:33:39 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeDE-0004X4-4E for rohc@ietf.org; Thu, 21 Oct 2004 10:46:45 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9LEXMHN007049; Thu, 21 Oct 2004 16:33:23 +0200 (MEST) In-Reply-To: <000501c4b733$bbbb83e0$443aa8c0@825pc13> References: <000501c4b733$bbbb83e0$443aa8c0@825pc13> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <289DA278-236E-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] Feedback channels in ROHC-TCP Date: Thu, 21 Oct 2004 16:33:21 +0200 To: "Tan Wee Lum" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Carsten Bormann , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit > I thought that a TCP connection would require a > full-duplex > channel to work? TCP does require bidirectional packet (L3) connectivity between the end hosts. Here we are talking about (L2) ROHC channels (see RFC3759). These are between two nodes on the path from one end host of the TCP connection to the other end host of the TCP connection. Any one (L2) link on this path need not be bidirectional -- the (L3) path back may traverse different (L2) links. Think satellite downlink from Sat-ISP A with a modem return path to an ISP B. The fact that packets ultimately do have to arrive back at the source of the packets that are being sent via A does not help with creating a bidirectional ROHC channel on the satellite. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 10:57:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10009 for ; Thu, 21 Oct 2004 10:57:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKea0-0005FI-UX for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 11:10:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe9N-0002Dn-CF; Thu, 21 Oct 2004 10:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe0i-0008DH-Gx for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:33:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06464 for ; Thu, 21 Oct 2004 10:33:46 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeDL-0004WZ-JK for rohc@ietf.org; Thu, 21 Oct 2004 10:46:52 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9LDWnLh030946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Oct 2004 15:32:50 +0200 Message-ID: <4177C8DE.3020502@effnet.com> Date: Thu, 21 Oct 2004 16:34:06 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] ROHC-FN & ROHC-TCP: Control fields References: <4177A2C6.90209@effnet.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Comments inline. Carsten Bormann wrote: > > On Oct 21 2004, at 13:51 Uhr, Kristofer Sandlund wrote: > >> Hi! >> >> Me and Ghyslain are trying to fix the final nits in the TCP packet >> formats, and with all the changes that the FN has undergone, it seems >> like the notion of control fields does not seem to be fully defined in >> the current WIP draft. >> >> Basically, we have two types of control fields: those that need to be >> stored in context (e.g. MSN, IP-ID behavior, ecn_used, etc), and those >> that are just "compressed_value" (e.g. discriminators). > > > The problem is that FN currently does not say anything about the context. > >> Those that update context are currently "defined" in default_methods >> or in the compressed format, which seems a bit weak, so we suggest >> that we add a "control_fields" section to encoding methods so that it >> is possible for the user to actually see which fields that need context. > > > That is an interesting proposal. > I would feel better if we could flesh out more of the context side of > the FN (as opposed to the uncompressed and the compressed side); once we > start to really understand this, we might want to have more (or > different) ways of saying this. > Yes that is probably needed, but for the next revision we'll go with this temporary solution, and we can hopefully flesh out something in Washington. >> With this syntax, it is clear which fields that are defined in this >> structure that sets context, which we don't think the old syntax does >> very well. > > > How about an annotation? I thought we'd agreed during our long discussion a few weeks ago that "annotations do not have any formal meaning", so I that would rule out annotations for this. > >> ****************** >> Now, over to how to use control fields in the TCP draft. >> Some control fields need to be known outside the scope of their >> definition, e.g. the ecn_used control field defined in the tcp header >> controls the presence of TOS bits in some compressed packets. > > > Now it gets interesting -- but you are not talking about the context (in > the sense of inter-packet memory), but you want to link different parts > of the spec using the same concept. > > Right now, we only have encoding method parameters for this purpose, and > (having done some work on 3095-FN) I know that this can get rather long > in the tooth. > It is doable, though. > > In your example, are you using ecn_used as a field name or as a number? > I'm seeing both, which is confusing. > Yep, I forgot to set ":uncomp_value" in some places, so it should have looked like this: tos_tc ::= irreg_tos_tc (ecn_used:uncomp_value); ip_ecn_flags ::= ip_irreg_ecn (ecn_used:uncomp_value); >> 1) How is the user supposed to know that the ecn_used in the base >> header should be the same field that was established by the dynamic >> chain in the TCP header? > > > You would have to use a parameter. But..... since we're doing the "chain" definition in English due to all the issues with this, the construction is done by the "user" and therefore parameters seem a bit awkward. But OTOH, I might just do that in English as well to say that the parameter should be taken from the TCP context. > >> 2) How should the IPv4 structure refer to this field since it is >> outside its own scope? > > > Ditto. > >> An answer to the second question might be to define a "global" constant > > > Well, I'd try not to mingle this with constants (which are, kind of, > constant). > >> let (ECN_USED == ecn_used:uncomp_value); > > > This looks like a "global parameter", i.e. an implicit parameter of > *every* encoding method that is handed down to *every other* encoding > method. Yes, I agree that this is not very good, but I just want something out the door and at least I managed to get a reaction and suggestions this time :) > > Again, this *can* be done using existing notation; however, if you have > too many of these parameters, the parameter lists do get rather long > (which you can see in 3095-FN). Maybe Eilert can produce an example > (I'm off to other things right now, unfortunately). > Any help appreciated! BR, Kristofer Sandlund, Effnet AB > Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 11:09:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11184 for ; Thu, 21 Oct 2004 11:09:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKelZ-0005WN-FP for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 11:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeQp-0003t6-2z; Thu, 21 Oct 2004 11:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeE8-00050l-IJ for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:47:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08623 for ; Thu, 21 Oct 2004 10:47:37 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeQk-0004wl-R0 for rohc@ietf.org; Thu, 21 Oct 2004 11:00:44 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9LElJeM016717; Thu, 21 Oct 2004 16:47:20 +0200 (MEST) In-Reply-To: <4177C682.7020902@effnet.com> References: <4177A042.7060304@effnet.com> <3FA40876-236A-11D9-8CDC-000A95DC4DB6@tzi.org> <4177C682.7020902@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B2DE7F1-2370-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding method Date: Thu, 21 Oct 2004 16:47:18 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , Carsten Bormann , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Oct 21 2004, at 16:24 Uhr, Kristofer Sandlund wrote: > since you cannot put a "let" in uncompressed_format or default_methods Then we should fix that (rather easy, I think). (I thought we could, but then I have a somewhat simplified view of what's in the FN draft.) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 11:09:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11270 for ; Thu, 21 Oct 2004 11:09:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKemN-0005Xx-4j for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 11:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeQt-00042w-9D; Thu, 21 Oct 2004 11:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeH6-0006Va-0l for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:50:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09021 for ; Thu, 21 Oct 2004 10:50:41 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeTi-00052T-G4 for rohc@ietf.org; Thu, 21 Oct 2004 11:03:47 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9LEoSvf018445; Thu, 21 Oct 2004 16:50:29 +0200 (MEST) In-Reply-To: <4177C8DE.3020502@effnet.com> References: <4177A2C6.90209@effnet.com> <4177C8DE.3020502@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8C18CE9E-2370-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] ROHC-FN & ROHC-TCP: Control fields Date: Thu, 21 Oct 2004 16:50:27 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , Carsten Bormann , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit On Oct 21 2004, at 16:34 Uhr, Kristofer Sandlund wrote: > I thought we'd agreed during our long discussion a few weeks ago that > "annotations do not have any formal meaning", so I that would rule out > annotations for this. Actually, the whole concept of context has no formal meaning at the current state, so this would not be a contradiction. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 11:10:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11340 for ; Thu, 21 Oct 2004 11:10:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKemq-0005Yo-Jb for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 11:23:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeRX-0004CL-Oi; Thu, 21 Oct 2004 11:01:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeL2-0000sD-IZ for rohc@megatron.ietf.org; Thu, 21 Oct 2004 10:54:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09640 for ; Thu, 21 Oct 2004 10:54:46 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeXf-0005A0-3Z for rohc@ietf.org; Thu, 21 Oct 2004 11:07:52 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9LEsWGa020589; Thu, 21 Oct 2004 16:54:33 +0200 (MEST) In-Reply-To: <4177C682.7020902@effnet.com> References: <4177A042.7060304@effnet.com> <3FA40876-236A-11D9-8CDC-000A95DC4DB6@tzi.org> <4177C682.7020902@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D0F0048-2371-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding method Date: Thu, 21 Oct 2004 16:54:30 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , Carsten Bormann , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Oct 21 2004, at 16:24 Uhr, Kristofer Sandlund wrote: > that makes the previous lines fail Lines don't fail, formats do (and, if there is no format combination, the method fails). 4.9.3.2: > More formally, the compressor can choose any combination of an > uncompressed format and a compressed format for which all fields > "succeed", i.e. the encoding methods succeed and there are > solutions > for all the let-statements (see Section 4.6). If there is no such > combination, the encoding method defined by the structure "fails". Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 21 20:27:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11982 for ; Thu, 21 Oct 2004 20:27:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnUR-00064O-2o for rohc-web-archive@ietf.org; Thu, 21 Oct 2004 20:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl6r-0005TK-Oj; Thu, 21 Oct 2004 18:08:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj7v-0003CX-9l; Thu, 21 Oct 2004 16:01:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14254; Thu, 21 Oct 2004 16:01:32 -0400 (EDT) Message-Id: <200410212001.QAA14254@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 16:01:32 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-nack-02.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : A Negative Acknowledgement Mechanism for Signaling Compression Author(s) : A. Roach Filename : draft-ietf-rohc-sigcomp-nack-02.txt Pages : 25 Date : 2004-10-21 This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-nack-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-nack-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-nack-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-21154804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-nack-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-nack-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154804.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Fri Oct 22 03:22:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07369 for ; Fri, 22 Oct 2004 03:22:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtxh-000899-BG for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 03:35:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtgp-0006DR-GH; Fri, 22 Oct 2004 03:18:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtYk-00039c-LI for rohc@megatron.ietf.org; Fri, 22 Oct 2004 03:10:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06437 for ; Fri, 22 Oct 2004 03:09:56 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtlS-0007s5-T2 for rohc@ietf.org; Fri, 22 Oct 2004 03:23:09 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9M68qLh001063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Oct 2004 08:08:53 +0200 Message-ID: <4178B25C.7000300@effnet.com> Date: Fri, 22 Oct 2004 09:10:20 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding method References: <4177A042.7060304@effnet.com> <3FA40876-236A-11D9-8CDC-000A95DC4DB6@tzi.org> <4177C682.7020902@effnet.com> <1B2DE7F1-2370-11D9-8CDC-000A95DC4DB6@tzi.org> In-Reply-To: <1B2DE7F1-2370-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Finking, Robert" , Ghyslain Pelletier X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit So, if it is that important to keep the "let" unmodified, then what if we just add a normal "if-else" construct that works the way _I_ want the "let" to work and we both get what we want? That should solve the problem of uncompressed_format/default_methods having variable appearance as well as the problem of having to duplicate everything in infinity. Anyone who are likely to ever read the spec will know how this work, so defining it should be easy! I could change back the packet formats very quickly to using "let" like you want it and use "if" to solve my remaining issues. /Kristofer Sandlund, Effnet AB Carsten Bormann wrote: > On Oct 21 2004, at 16:24 Uhr, Kristofer Sandlund wrote: > >> since you cannot put a "let" in uncompressed_format or default_methods > > > Then we should fix that (rather easy, I think). > (I thought we could, but then I have a somewhat simplified view of > what's in the FN draft.) > > Gruesse, Carsten > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 04:30:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12074 for ; Fri, 22 Oct 2004 04:30:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKv1u-0000um-N0 for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 04:44:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKueX-0005fO-IO; Fri, 22 Oct 2004 04:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKua0-0003ce-7a for rohc@megatron.ietf.org; Fri, 22 Oct 2004 04:15:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11228 for ; Fri, 22 Oct 2004 04:15:18 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKumi-0000hE-Bx for rohc@ietf.org; Fri, 22 Oct 2004 04:28:31 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9M8FDWR022311 for ; Fri, 22 Oct 2004 10:15:13 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 10:15:13 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 10:15:13 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Kristofer Sandlund'" , Carsten Bormann Subject: RE: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod Date: Fri, 22 Oct 2004 10:15:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Oct 2004 08:15:13.0786 (UTC) FILETIME=[419A2DA0:01C4B80F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Eilert Brinkmann , "West, Mark" , "Finking, Robert" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 I agree with Kristofer here. Let's add the "if-else" conditional and leave the "let" statement as it is. We can also add a clarification in the ROHC-FN draft about the environnement of the "let" failing. /Ghyslain > -----Original Message----- > From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com] > Sent: den 22 oktober 2004 09:10 > To: Carsten Bormann > Cc: Eilert Brinkmann; West, Mark; rohc@ietf.org; Lars-Erik Jonsson > (LU/EAB); Finking, Robert; Ghyslain Pelletier (LU/EAB) > Subject: Re: [rohc] ROHC-FN: Changing the behavior of the > "let" encoding > method > > > So, if it is that important to keep the "let" unmodified, > then what if we just > add a normal "if-else" construct that works the way _I_ want > the "let" to work > and we both get what we want? > That should solve the problem of > uncompressed_format/default_methods having > variable appearance as well as the problem of having to > duplicate everything in > infinity. Anyone who are likely to ever read the spec will > know how this work, > so defining it should be easy! > > I could change back the packet formats very quickly to using > "let" like you want > it and use "if" to solve my remaining issues. > > /Kristofer Sandlund, Effnet AB > > Carsten Bormann wrote: > > On Oct 21 2004, at 16:24 Uhr, Kristofer Sandlund wrote: > > > >> since you cannot put a "let" in uncompressed_format or > default_methods > > > > > > Then we should fix that (rather easy, I think). > > (I thought we could, but then I have a somewhat simplified view of > > what's in the FN draft.) > > > > Gruesse, Carsten > > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 05:27:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15132 for ; Fri, 22 Oct 2004 05:27:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKvuy-0001qS-Uh for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 05:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvh3-0003Uo-Ak; Fri, 22 Oct 2004 05:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvgH-0002vZ-FH for rohc@megatron.ietf.org; Fri, 22 Oct 2004 05:25:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15036 for ; Fri, 22 Oct 2004 05:25:50 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKvt2-0001nl-Ui for rohc@ietf.org; Fri, 22 Oct 2004 05:39:05 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9M9Pbb1017803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2004 11:25:39 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i9M9Pbr2011982; Fri, 22 Oct 2004 11:25:37 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod References: From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Fri, 22 Oct 2004 11:25:36 +0200 In-Reply-To: (Ghyslain Pelletier's message of "Fri, 22 Oct 2004 10:15:08 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , "Finking, Robert" , "'Kristofer Sandlund'" , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 "Ghyslain Pelletier (LU/EAB)" wrote: > I agree with Kristofer here. Let's add the "if-else" conditional and > leave the "let" statement as it is. At least I like that more than changes to the old meaning of let. However, I think the present problems can be solved even without this addition, and especially without introducing conditionals in field order lists. In the specification I see three places where the proposed new "let" syntax is used in a way that has no direct equivalent in the old syntax. They are all distinctions between IPv4 und IPv6 in the co_baseheader structure. One use is in default_methods: default_methods = { [...] let (version:uncomp_value == 6) { flow_label ::= static; }; let (version:uncomp_value == 4) { header_length ::= uncompressed_value (4,5); length ::= inferred_ip_v4_length; ip_id ::= irregular(16); rf ::= static; df ::= static; mf ::= static; frag_offset ::= static; checksum ::= inferred_ip_checksum; }; [...] }; I think, simply removing the conditions and defining the encodings unconditionally wouldn't do any harm here. If a field is not present in a format, encodings defined for this field remain unused. Then in format_co_common there are these lines: let (version:uncomp_value == 4) { df ::= irregular(1); } let (version:uncomp_value == 6) { df ::= compressed_value(1,0); } This could still be done the "old way", i.e. by using something like df ::= dont_fragment(version:uncomp_value); and a structure which defines the two different formats: dont_fragment(version) === { uncompressed_format = df; compressed_format_v4 = df, { let (version == 4); df ::= irregular(1); }; compressed_format_v6 = df, { let (version == 6); df ::= compressed_value(1,0); }; }; So the only remaining problem would be the selection between the two uncompressed formats which you do by conditionals in the field order list: uncompressed_format = version, tos_tc, ip_ecn_flags, ttl_hopl, next_header, src_addr, dest_addr, let (version:uncomp_value == 6) { flow_label, }, let (version:uncomp_value == 4) { header_length, length, ip_id, rf, df, mf, frag_offset, checksum, }, [...TCP part...]; By the way: The IPv6 payload length field is missing and this field order list does not give the correct order of fields in uncompressed IP headers -- neither for IPv4 nor for IPv6. Is this simply a mistake or do I have missed anything here? And the current specification does not bind version:uncomp_length. Back to the original problem -- how about using two diffent uncompressed formats instead of only one with conditional parts in it's field order list? A question would be how to bind the value of the version field according to the used uncompressed format. Maybe we could extend the FN to allow the specification of let expressions (and possibly field encodings, too?) in uncompressed formats in a sense like "default methods specific to a single uncompressed format". I.e., unlike things defined in default_methods, which are included in all compressed formats in every case, these would be included only when a packet has the specific uncompressed format. So in the TCP case the uncompressed formats could look like this: uncompressed_format_v4 = version, header_length, tos_tc, ip_ecn_flags, length, ip_id, df, mf, rf, frag_offset, ttl_hopl, next_header, checksum, src_addr, dest_addr, [...TCP part...], { let (version:uncomp_value == 4); }; uncompressed_format_v6 = version, tos_tc, ip_ecn_flags, flow_label, payload_length, next_header, ttl_hopl, src_addr, dest_addr, [...TCP part...], { let (version:uncomp_value == 6); }; An alternative would be to deduce the version number from the presence of version specific fields in the header. This might be possible even without any extentions to the FN if we assume that for fields which are not present in the uncompressed header (fieldname:uncomp_value == null) is true. > We can also add a clarification in the ROHC-FN draft about the > environnement of the "let" failing. I would appreciate that, as well as an addition that allows let in default_methods (meaning that this let expression will be added to all compressed formats, but unlike default field encodings can not be overridden). Regards Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 06:31:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19089 for ; Fri, 22 Oct 2004 06:31:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwuQ-0002xS-Qu for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 06:44:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKwaJ-0007l9-Ih; Fri, 22 Oct 2004 06:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKwVP-0005DP-Sk for rohc@megatron.ietf.org; Fri, 22 Oct 2004 06:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18367 for ; Fri, 22 Oct 2004 06:18:40 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwi1-0002kH-N2 for rohc@ietf.org; Fri, 22 Oct 2004 06:31:56 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9MAIUR2031319 for ; Fri, 22 Oct 2004 12:18:30 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 12:18:30 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Oct 2004 12:18:30 +0200 Message-ID: From: "Ghyslain Pelletier (LU/EAB)" To: "'Eilert Brinkmann'" Subject: RE: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod Date: Fri, 22 Oct 2004 12:18:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Oct 2004 10:18:30.0382 (UTC) FILETIME=[7A5128E0:01C4B820] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , "Finking, Robert" , "'Kristofer Sandlund'" , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi Eilert, I need to think a little more about your suggestion regarding > Back to the original problem -- how about using two diffent > uncompressed formats instead of only one with conditional parts in > it's field order list? Right now, I'd like to look a little more on the first alternative that you have proposed. If I understand correctly, in other words you suggest to: - have an uncompressed format for each IP version (IPv4+TCP, IPv6+TCP) - have a "let" in the uncompressed format that makes the format "fail" based on the version field, and then only have a single set of compressed format that can handle either case. Is this correct? > > We can also add a clarification in the ROHC-FN draft about the > > environnement of the "let" failing. > > I would appreciate that, as well as an addition that allows let in > default_methods (meaning that this let expression will be added to all > compressed formats, but unlike default field encodings can not be > overridden). Please clarify the addition you'd like to have with respect to a "let" statement failing in the default methods? What I am trying to get at is that I feel I need to add a restriction into this clarification as to that a "let" statement must be written as part of a compressed format in the default method section, i.e. it cannot occur by itself in that section. In other words, a "let" statement must not be in the direct scope of a structure (===), but rather in the direct scope of a compressed format. This is because only a compressed format conceptually can fail, a structure cannot fail. Is this correct? _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 07:20:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24248 for ; Fri, 22 Oct 2004 07:20:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxgL-0003pn-1J for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 07:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxSx-0002Bf-8M; Fri, 22 Oct 2004 07:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxQo-0001Eh-Or for rohc@megatron.ietf.org; Fri, 22 Oct 2004 07:18:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24062 for ; Fri, 22 Oct 2004 07:17:59 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxda-0003ma-Oa for rohc@ietf.org; Fri, 22 Oct 2004 07:31:15 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9MAGwLh001727 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Oct 2004 12:16:58 +0200 Message-ID: <4178EC85.2030807@effnet.com> Date: Fri, 22 Oct 2004 13:18:29 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eilert Brinkmann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: 7bit Cc: "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , Carsten Bormann , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Hi Eilert and thanks for your suggested solutions. Some comments inline. Eilert Brinkmann wrote: > "Ghyslain Pelletier (LU/EAB)" wrote: > >>I agree with Kristofer here. Let's add the "if-else" conditional and >>leave the "let" statement as it is. > > > At least I like that more than changes to the old meaning of > let. However, I think the present problems can be solved even without > this addition, and especially without introducing conditionals in > field order lists. > > In the specification I see three places where the proposed new "let" > syntax is used in a way that has no direct equivalent in the old > syntax. They are all distinctions between IPv4 und IPv6 in the > co_baseheader structure. One use is in default_methods: > > default_methods = > { > [...] > let (version:uncomp_value == 6) { > flow_label ::= static; > }; > let (version:uncomp_value == 4) { > header_length ::= uncompressed_value (4,5); > length ::= inferred_ip_v4_length; > ip_id ::= irregular(16); > rf ::= static; > df ::= static; > mf ::= static; > frag_offset ::= static; > checksum ::= inferred_ip_checksum; > }; > [...] > }; > > I think, simply removing the conditions and defining the encodings > unconditionally wouldn't do any harm here. If a field is not present > in a format, encodings defined for this field remain unused. > Ok, I can live with that. > Then in format_co_common there are these lines: > > let (version:uncomp_value == 4) { > df ::= irregular(1); > } > let (version:uncomp_value == 6) { > df ::= compressed_value(1,0); > } > > This could still be done the "old way", i.e. by using something like > > df ::= dont_fragment(version:uncomp_value); > > and a structure which defines the two different formats: > > dont_fragment(version) === > { > uncompressed_format = df; > > compressed_format_v4 = df, > { > let (version == 4); > df ::= irregular(1); > }; > > compressed_format_v6 = df, > { > let (version == 6); > df ::= compressed_value(1,0); > }; > }; > Ok that works for me. > > So the only remaining problem would be the selection between the two > uncompressed formats which you do by conditionals in the field order > list: > > uncompressed_format = version, > tos_tc, > ip_ecn_flags, > ttl_hopl, > next_header, > src_addr, > dest_addr, > let (version:uncomp_value == 6) { > flow_label, > }, > let (version:uncomp_value == 4) { > header_length, > length, > ip_id, > rf, > df, > mf, > frag_offset, > checksum, > }, > [...TCP part...]; > > By the way: The IPv6 payload length field is missing and this field > order list does not give the correct order of fields in uncompressed > IP headers -- neither for IPv4 nor for IPv6. Is this simply a mistake > or do I have missed anything here? Crap, does the FN force order also in the uncompressed format? I thought it was only in the compressed formats. I can fix that since it makes no difference to me. > And the current specification does > not bind version:uncomp_length. > Eh? Does it need to? (if it does, then please suggest text that fixes this to the FN-draft and mail it to Ghyslain) > Back to the original problem -- how about using two diffent > uncompressed formats instead of only one with conditional parts in > it's field order list? A question would be how to bind the value of > the version field according to the used uncompressed format. Maybe we > could extend the FN to allow the specification of let expressions (and > possibly field encodings, too?) in uncompressed formats in a sense > like "default methods specific to a single uncompressed format". I.e., > unlike things defined in default_methods, which are included in all > compressed formats in every case, these would be included only when a > packet has the specific uncompressed format. So in the TCP case the > uncompressed formats could look like this: > > uncompressed_format_v4 = version, > header_length, > tos_tc, > ip_ecn_flags, > length, > ip_id, > df, > mf, > rf, > frag_offset, > ttl_hopl, > next_header, > checksum, > src_addr, > dest_addr, > [...TCP part...], > { > let (version:uncomp_value == 4); > }; > > uncompressed_format_v6 = version, > tos_tc, > ip_ecn_flags, > flow_label, > payload_length, > next_header, > ttl_hopl, > src_addr, > dest_addr, > [...TCP part...], > { > let (version:uncomp_value == 6); > }; > This change would be ok with me. What kind of worries me is that currently, "uncompressed_format" is a reserved work, and now we'd have multiple different. Will this be a problem? If we do this, we would have to update some FN text. Could you suggest some text for the "structures" section that would explain this? > An alternative would be to deduce the version number from the presence > of version specific fields in the header. This might be possible even > without any extentions to the FN if we assume that for fields which > are not present in the uncompressed header > (fieldname:uncomp_value == null) is true. > This I don't like, so I think your previous suggestion is a lot better. > >>We can also add a clarification in the ROHC-FN draft about the >>environnement of the "let" failing. > > > I would appreciate that, as well as an addition that allows let in > default_methods (meaning that this let expression will be added to all > compressed formats, but unlike default field encodings can not be > overridden). Again, please suggest some text, it doesn't have to be perfect just as long as it's good enough for getting out a draft on monday, so we can have some common ground to discuss from and show the rest of the list where we are right now. I'll immediately update the tcp-pf with these suggestions and will check it into the CVS (we can always fall back to the old stuff). BR, Kristofer Sandlund, Effnet AB > > Regards > > Eilert > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 08:22:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27615 for ; Fri, 22 Oct 2004 08:22:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyeT-0004tQ-CA for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 08:36:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyPz-00026h-Pm; Fri, 22 Oct 2004 08:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyLY-0000mV-HT for rohc@megatron.ietf.org; Fri, 22 Oct 2004 08:16:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27158 for ; Fri, 22 Oct 2004 08:16:38 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyYL-0004mh-4j for rohc@ietf.org; Fri, 22 Oct 2004 08:29:53 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9MCGNml009320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2004 14:16:25 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i9MCGMtg013109; Fri, 22 Oct 2004 14:16:22 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: Kristofer Sandlund Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod References: <4178EC85.2030807@effnet.com> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Fri, 22 Oct 2004 14:16:22 +0200 In-Reply-To: <4178EC85.2030807@effnet.com> (Kristofer Sandlund's message of "Fri, 22 Oct 2004 13:18:29 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , Carsten Bormann , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Kristofer Sandlund wrote: > Crap, does the FN force order also in the uncompressed format? I > thought it was only in the compressed formats. I can fix that since it > makes no difference to me. Well, these lists are called field order lists ;-) At the end of section 3.2 the draft explicitly says that the list "indicates the order of fields in the uncompressed header", the same in sections 4.9.1 and 4.9.1.1. Maybe the second paragraph in 4.9.1.1 does not clear enough say that the notator is free to change the arrangement of uncompressed fields regarding field boundaries, but not field order? >> And the current specification does >> not bind version:uncomp_length. > > Eh? Does it need to? (if it does, then please suggest text that fixes > this to the FN-draft and mail it to Ghyslain) My understanding was that a FN specification should specify everything needed for the mapping between uncompressed and compressed headers, which would include all information about involved packet formats like order and length of fields in the compressed as well as the uncompressed headers. Am I wrong with this? > This change would be ok with me. What kind of worries me is that > currently, "uncompressed_format" is a reserved work, and now we'd have > multiple different. Will this be a problem? > If we do this, we would have to update some FN text. Could you suggest > some text for the "structures" section that would explain this? This is already part of the "multiple formats" section, especially in section 4.9.3.1: | Similarly, if multiple uncompressed formats are defined, they must be | defined using names beginning with "uncompressed_format". Also section 4.9.5 contains an example with two different uncompressed formats in one structure. >> An alternative would be to deduce the version number from the presence >> of version specific fields in the header. This might be possible even >> without any extentions to the FN if we assume that for fields which >> are not present in the uncompressed header >> (fieldname:uncomp_value == null) is true. > > This I don't like, so I think your previous suggestion is a lot better. I agree. Unfortunately I'm in a meeting now. I will try to write some suggestions for text changes later. Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 08:45:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29064 for ; Fri, 22 Oct 2004 08:45:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyzr-0005Ia-W1 for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 08:58:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKydB-00079Z-FJ; Fri, 22 Oct 2004 08:34:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKybe-0006CK-Az for rohc@megatron.ietf.org; Fri, 22 Oct 2004 08:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28431 for ; Fri, 22 Oct 2004 08:33:16 -0400 (EDT) Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyoR-00055s-7o for rohc@ietf.org; Fri, 22 Oct 2004 08:46:31 -0400 Received: from effnet.com (c-b97c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.185]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id i9MBWGLh001938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Oct 2004 13:32:17 +0200 Message-ID: <4178FE2C.5040904@effnet.com> Date: Fri, 22 Oct 2004 14:33:48 +0200 From: Kristofer Sandlund Organization: Effnet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eilert Brinkmann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod References: <4178EC85.2030807@effnet.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , Carsten Bormann , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Comments inline Eilert Brinkmann wrote: > Kristofer Sandlund wrote: > >>Crap, does the FN force order also in the uncompressed format? I >>thought it was only in the compressed formats. I can fix that since it >>makes no difference to me. > > > Well, these lists are called field order lists ;-) At the end of > section 3.2 the draft explicitly says that the list "indicates the > order of fields in the uncompressed header", the same in sections > 4.9.1 and 4.9.1.1. Maybe the second paragraph in 4.9.1.1 does not > clear enough say that the notator is free to change the arrangement of > uncompressed fields regarding field boundaries, but not field order? > You're right, but the text could be more clear. It does not clearly state that changing order is illegal, so an extra sentence there might make it even better. Ghyslain, can you fix that? > >>>And the current specification does >>>not bind version:uncomp_length. >> >>Eh? Does it need to? (if it does, then please suggest text that fixes >>this to the FN-draft and mail it to Ghyslain) > > > My understanding was that a FN specification should specify everything > needed for the mapping between uncompressed and compressed headers, > which would include all information about involved packet formats like > order and length of fields in the compressed as well as the > uncompressed headers. Am I wrong with this? > Hmm... but (it might be that I'm misunderstanding you here) does any field get its length specified in uncompressed_format? So, I don't see why version should be an issue while the others would not be an issue. But if there's a problem then go ahead and fix it, I don't have to understand the exact details... > >>This change would be ok with me. What kind of worries me is that >>currently, "uncompressed_format" is a reserved work, and now we'd have >>multiple different. Will this be a problem? >>If we do this, we would have to update some FN text. Could you suggest >>some text for the "structures" section that would explain this? > > > This is already part of the "multiple formats" section, especially in > section 4.9.3.1: > > | Similarly, if multiple uncompressed formats are defined, they must be > | defined using names beginning with "uncompressed_format". > > Also section 4.9.5 contains an example with two different > uncompressed formats in one structure. I clearly have some reading problems today. You're right. One less issue to worry about. > > >>>An alternative would be to deduce the version number from the presence >>>of version specific fields in the header. This might be possible even >>>without any extentions to the FN if we assume that for fields which >>>are not present in the uncompressed header >>>(fieldname:uncomp_value == null) is true. >> >>This I don't like, so I think your previous suggestion is a lot better. > > > I agree. > > Unfortunately I'm in a meeting now. I will try to write some > suggestions for text changes later. Sounds good. /Kristofer > > Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 08:46:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29162 for ; Fri, 22 Oct 2004 08:46:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKz0m-0005K0-Gh for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 08:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKynR-0002BX-Mz; Fri, 22 Oct 2004 08:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyeK-0007YW-7j for rohc@megatron.ietf.org; Fri, 22 Oct 2004 08:36:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28545 for ; Fri, 22 Oct 2004 08:36:02 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyr6-00058g-8V for rohc@ietf.org; Fri, 22 Oct 2004 08:49:17 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9MCZjlv021519; Fri, 22 Oct 2004 14:35:46 +0200 (MEST) In-Reply-To: <4178FE2C.5040904@effnet.com> References: <4178EC85.2030807@effnet.com> <4178FE2C.5040904@effnet.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod Date: Fri, 22 Oct 2004 14:35:44 +0200 To: Kristofer Sandlund X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Eilert Brinkmann , "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , Carsten Bormann , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Oct 22 2004, at 14:33 Uhr, Kristofer Sandlund wrote: > changing order is illegal Well, changing the order of the uncompressed fields is certainly legal, it just means that you get a different uncompressed packet (i.e., your uncompressed packet is carved up into fields in a different way)... Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Oct 22 09:04:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00679 for ; Fri, 22 Oct 2004 09:04:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzJ0-0005kP-BO for rohc-web-archive@ietf.org; Fri, 22 Oct 2004 09:18:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKz3M-0008Jz-Rm; Fri, 22 Oct 2004 09:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKywb-0005OO-Us for rohc@megatron.ietf.org; Fri, 22 Oct 2004 08:54:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29908 for ; Fri, 22 Oct 2004 08:54:55 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKz9N-0005XX-Rj for rohc@ietf.org; Fri, 22 Oct 2004 09:08:11 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9MCsd9O001803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2004 14:54:40 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i9MCsc6Z013331; Fri, 22 Oct 2004 14:54:38 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: Kristofer Sandlund Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod References: <4178EC85.2030807@effnet.com> <4178FE2C.5040904@effnet.com> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Fri, 22 Oct 2004 14:54:38 +0200 In-Reply-To: <4178FE2C.5040904@effnet.com> (Kristofer Sandlund's message of "Fri, 22 Oct 2004 14:33:48 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , Carsten Bormann , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Kristofer Sandlund wrote: > Eilert Brinkmann wrote: >> Kristofer Sandlund wrote: >>>>And the current specification does >>>>not bind version:uncomp_length. >>> >>>Eh? Does it need to? (if it does, then please suggest text that fixes >>>this to the FN-draft and mail it to Ghyslain) >> My understanding was that a FN specification should specify >> everything >> needed for the mapping between uncompressed and compressed headers, >> which would include all information about involved packet formats like >> order and length of fields in the compressed as well as the >> uncompressed headers. Am I wrong with this? > > Hmm... but (it might be that I'm misunderstanding you here) does any > field get its length specified in uncompressed_format? So, I don't see > why version should be an issue while the others would not be an > issue. But if there's a problem then go ahead and fix it, I don't have > to understand the exact details... In most cases the uncomp_length attributes are bound by the encoding methods used for the fields, e.g.: - static: same length as in context - irregular: length specified by the method argument - uncompressed_value: uncomp_length specified by argument , compressed side does not exist or has comp_length == 0 - compressed_value and crc: comp_length specified by argument, uncompressed field does not exist or has uncomp_length == 0 But the specification does not give a "normal" encoding method for version and binds only uncomp_value using a let expression. So we could add let (version:uncomp_length == 4); or replace let (version:uncomp_value == 4); with version ::= uncompressed_value(4, 4); (assuming we can specify a field encoding in every place where let can be used). Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 25 03:35:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27015 for ; Mon, 25 Oct 2004 03:35:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzbp-0007sD-1d for rohc-web-archive@ietf.org; Mon, 25 Oct 2004 03:49:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzNW-00089Z-7Z; Mon, 25 Oct 2004 03:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzMA-00082T-3K for rohc@megatron.ietf.org; Mon, 25 Oct 2004 03:33:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26772 for ; Mon, 25 Oct 2004 03:33:26 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzZM-0007pN-Vs for rohc@ietf.org; Mon, 25 Oct 2004 03:47:19 -0400 Received: from dominion.informatik.uni-bremen.de (dominion.informatik.uni-bremen.de [134.102.218.70]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9P7Ww2f025313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2004 09:32:59 +0200 (MEST) Received: (from eilert@localhost) by dominion.informatik.uni-bremen.de (8.12.8/8.12.8/Submit) id i9P7Wvc5005659; Mon, 25 Oct 2004 09:32:57 +0200 X-Authentication-Warning: dominion.informatik.uni-bremen.de: eilert set sender to eilert@tzi.org using -f To: Kristofer Sandlund Subject: Re: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod References: <4178EC85.2030807@effnet.com> From: Eilert Brinkmann Organization: University of Bremen / TZI Date: Mon, 25 Oct 2004 09:32:57 +0200 In-Reply-To: <4178EC85.2030807@effnet.com> (Kristofer Sandlund's message of "Fri, 22 Oct 2004 13:18:29 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "West, Mark" , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , Carsten Bormann , "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Kristofer Sandlund wrote: > Again, please suggest some text, it doesn't have to be perfect just as > long as it's good enough for getting out a draft on monday, so we can > have some common ground to discuss from and show the rest of the list > where we are right now. Sorry for being a bit late, but here are suggestions for a few text changes regarding the topics discussed on friday. (I refer to draft-ietf-rohc-formal-notation-04-V1-EPLGHPE-pa0-raf5.txt as this seems to be the latest version I have.) - Section 4.6 ("Let") Add the following clarification: A let-statement is always part of a field encodings list. - Section 4.9.1.1 ("uncompressed_format") Add the following paragraph: An uncompressed format may contain a field encodings list. Encoding methods specified therein are used whenever a packet with this uncompressed format is being encoded, regardless of the selected compressed format. If an uncompressed format contains let-statements, the encoding of a packet with this uncompressed format can only succeed if the specified expressions evaluate to true (see Section 4.9.3.2). To make clear that the length of fields in the uncompressed header must be defined by an FN specification, the following text could be inserted after the first paragraph of 4.9.1.1: (Note that it is not sufficient that the annotations say this -- the encoding methods defined for the fields must define the uncomp_length attribute so there is an unambiguous mapping from the bits in the uncompressed header to the fields listed in the field order list.) - Section 4.9.3.3 ("Default Encoding Methods - default_methods") Add the following paragraph: The field encodings list of default_methods may also contain let-statements. In this case every compressed format of the structure can only succeed if the specified expressions evaluate to true. Note that let-statements can not be overridden in compressed formats. Regards Eilert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 25 06:59:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13090 for ; Mon, 25 Oct 2004 06:59:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM2nE-0003d6-NK for rohc-web-archive@ietf.org; Mon, 25 Oct 2004 07:13:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2Yh-0001y1-Nc; Mon, 25 Oct 2004 06:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2Yc-0001vz-9t for rohc@megatron.ietf.org; Mon, 25 Oct 2004 06:58:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13044 for ; Mon, 25 Oct 2004 06:58:31 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM2m3-0003bG-5Q for rohc@ietf.org; Mon, 25 Oct 2004 07:12:27 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i9PAuIBc013001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Oct 2004 11:56:19 +0100 (BST) Message-ID: <417CDBD2.1070708@erg.abdn.ac.uk> Date: Mon, 25 Oct 2004 11:56:18 +0100 From: gorry fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] Feedback channels in ROHC-TCP References: <000501c4b733$bbbb83e0$443aa8c0@825pc13> <289DA278-236E-11D9-8CDC-000A95DC4DB6@tzi.org> In-Reply-To: <289DA278-236E-11D9-8CDC-000A95DC4DB6@tzi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-ERG-MailScanner-To: cabo@tzi.org, rohc@ietf.org, wltan3@ie.cuhk.edu.hk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: rohc@ietf.org, Tan Wee Lum X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gf@erg.abdn.ac.uk List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit I agree that an Asymmetric Network Path is an important case. Thats is: a link may see only forward packets, or only return direction (ACK/Control/etc) packets, or both. Although you could optimise for a (fairly common) case where you see all packets in both directions via the same link. This is not required (unless, of course, this is the first or final link along the end to end internet path :-)). Note that tunnel encapsulations, and security need not be the same in both directions either:-) Gorry Carsten Bormann wrote: >> I thought that a TCP connection would require a >> full-duplex >> channel to work? > > > TCP does require bidirectional packet (L3) connectivity between the end > hosts. > > Here we are talking about (L2) ROHC channels (see RFC3759). > These are between two nodes on the path from one end host of the TCP > connection to the other end host of the TCP connection. > Any one (L2) link on this path need not be bidirectional -- the (L3) > path back may traverse different (L2) links. > > Think satellite downlink from Sat-ISP A with a modem return path to an > ISP B. > The fact that packets ultimately do have to arrive back at the source of > the packets that are being sent via A does not help with creating a > bidirectional ROHC channel on the satellite. > > Gruesse, Carsten > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 25 17:45:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18695 for ; Mon, 25 Oct 2004 17:45:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCrs-0003jc-6b for rohc-web-archive@ietf.org; Mon, 25 Oct 2004 17:59:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBRk-00014m-Qi; Mon, 25 Oct 2004 16:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAzV-0003iY-Rg for rohc@megatron.ietf.org; Mon, 25 Oct 2004 15:58:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28783 for ; Mon, 25 Oct 2004 15:58:51 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBD1-0006Hp-6K for rohc@ietf.org; Mon, 25 Oct 2004 16:12:51 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Oct 2004 20:59:28 +0100 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V2Q3RK8B; Mon, 25 Oct 2004 20:59:29 +0100 From: "West, Mark" To: Reiner Ludwig Date: Mon, 25 Oct 2004 20:58:09 +0100 (GMT Daylight Time) In-Reply-To: <6.1.1.1.1.20040913133004.02908e68@imap.eed.ericsson.se> Message-ID: References: <6.1.1.1.1.20040913133004.02908e68@imap.eed.ericsson.se> X-X-Sender: maw1@maw-laptop.comm.ad.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "Gorry Fairhurst \(E-mail\)" , mathis@psc.edu, "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" , "'Carsten Bormann \(E-mail\)'" , "Kristofer Sandlund \(E-mail\)" , "Ghyslain Pelletier \(LU/EAB\)" , Mark Allman Subject: [rohc] Re: WG last-call for draft-ietf-rohc-tcp-field-behavior-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Hi Reiner, all, > > Sorry for being late ... Given the time it's taken me to get around to incorporating these, I think I'm the one who should be apologising..! > > I think this document is ready to go! > > Some minor comments: > -------------------- > > - Section 3.1.2 discusses IPv4 header fields and this statement caught my attention: > "The More Fragments (MF) flag is expected to be zero because > fragmentation is generally not expected." Is this a reasonable > assumption? I have added Matt Mathis to the cc: of this mail, and would > like to hear from him what he thinks. Since Matt has done a lot of work > on PMTU discovery, I'm sure that he knows about these things. > I've weakened the text -- it seems that 'generally not expected' is a slightly optimistic view! Anyway, the point is that this is not, perhaps, too important: if you have a fragmented packet then there are two consequences... (i) the fragment containing the TCP header is probably comparatively large, so if compression is not optimal it's not a big deal; and (ii) the TCP profile won't be used to compress subsequent fragments (because there's no TCP header). Plus, I seem to recall that Matt isn't a great fan of fragmentation -- and having a compression profile that does not encourage fragmentation seems to be reasonable! > - Section 3.1.2, bullet "o Protocol": It seems that the text under this > bullet is a copy/paste from a previous bullet (IPv6/NextHeader). > Probably the wording should be different. Whoops! Updated... > > - Section 4.3: > "(1) On the server side, the port number is likely to be a well-known > value. On the client side, the port number is generally selected > by the stack automatically. Whether the port number is replicable > depends upon how the stack chooses the port number. However, most > implementations use a simple scheme which sequentially picks the > next available port number. This is clearly exploitable in a > compression scheme." If I understand the recent discussions about > "reset attacks" in the TCPM WG correctly, I'm not sure whether > implementers should be encouraged to rely on the fact that clients > simply sequentially pick the next available port number. I suggest > asking Mark Allman about this one. > I guess the jury's still out on the solution to blind reset -- however, I've changed the text anyway to suggest that relying on / exploiting this assumption about behavior may be fragile (in that, like the ISS, this behavior may change) > - Section 5.2.1: > "The Nagle algorithm is an optimisation and not required to be used." > RFC1122 says that a TCP SHOULD implement Nagle, and as far as I know it > is turned on by default in all common TCP implementations. > Recent personal experience has indeed confirmed that Nagle is turned on by default! I've updated the text accordingly... > - Section 5.3.2 discusses various options and for some options, e.g., > POC and T/TCP, and concludes that in practice these options are never > seen. Why then is it a requirement that "the header compression scheme > should be able to encode it"? > The wording of this (something that Gorry also picked up on) is far too sloppy. I've tried to be stricter about the concepts of 'supporting' [should be able to handle anything] and 'optimised for' [no point in optimising rare cases]. In this case, there's no requirement for 'optimal' treatment; but it must be possible to carry all options. > - Section 5.3.2, last paragraph: > "In the discussion above regarding timestamps it is pointed out that > there is the possibility (at some time in the future) of negotiations > being permitted more generally than in the SYN packets at connection > set-up. Although there seems to be no compelling need to optimise > for this, it is worth pointing out that the compression scheme should > be able to cope with arbitrary options appearing at any point within > the flow." I don't recall any such proposal in the transport area, > and I don't understand why this last recommendation is made. Again, I > suggest asking Mark Allman about this one. > We kicked this one around a bit, shortly after these comments were circulated. I think that our conclusion was that there *had* been some discussion along these lines, but it was perhaps not appropriate to put this text in. The draft now just makes more general statements about not assuming where options may occur. Hopefully this is more generic and captures the spirit of what matters with regard to header compression. It incidentally encompasses the idea that timestamps could, conceivably, start/stop mid-flow. > I will send a few editing nits directly to the authors. > > ///Reiner > Cheers, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 25 19:33:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16137 for ; Mon, 25 Oct 2004 19:33:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEYd-0003a1-JX for rohc-web-archive@ietf.org; Mon, 25 Oct 2004 19:47:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBYk-0002rC-Np; Mon, 25 Oct 2004 16:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBFp-0004CK-1y for rohc@megatron.ietf.org; Mon, 25 Oct 2004 16:15:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02005 for ; Mon, 25 Oct 2004 16:15:42 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBTJ-00073Z-RI for rohc@ietf.org; Mon, 25 Oct 2004 16:29:43 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Oct 2004 21:16:23 +0100 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V2Q3RK8H; Mon, 25 Oct 2004 21:16:26 +0100 From: "West, Mark" To: Gorry Fairhurst Date: Mon, 25 Oct 2004 21:15:06 +0100 (GMT Daylight Time) In-Reply-To: Message-ID: References: X-X-Sender: maw1@maw-laptop.comm.ad.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: rohc@ietf.org Subject: [rohc] Re: ROHC WGLC (NiTs): draft-ietf-rohc-tcp-field-behavior-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi Gorry, Nothing *too* controversial here (I hope!)... I've incorporated updates into the -04 draft and I think that I've captured all of these. A couple of points, inline. Cheers, Mark. > > Nit: Page 4: Intro, para 3: > "A less stable but more detailed analysis is done in section 5..." > - Perhaps a poor choice of words: if the section is not stable, we should > not publish as an RFC :-)? > - Please could you suggest some clearer words to describes the constraints > in section 5. I have no idea why it says 'less stable', so I took that out :-) > > Nit: Page 7: Source and Destination addresses > - Are we considering possible Tunnel encapsulations at this point? > - If so, is this referring to the inner-most IP header (directly preceding > the TCP header)? > Yes, we are considering tunnel encapsulations -- I've updated the text to allow for this (the issue of flow separation is something that is, in part, at the discretion of the compressor). < > Nit: Page 22: Section 5.2.1 para 7. > "It would also be desirable to.." > -> Is the WG confident enough to say: > "It is desirable to" > Yes! > > NiT: Page 33: Section 6.3: para 1 > (i) "not that onerous" > - This text is unclear, in terms of what? > - Do you mean there are fewer bytes? > i.e. overhead is less significant (i.e. than 10% of capacity for an MSS of > 536B and less than 3% for 1460B)? > Yes, I mean that the percentage of header bytes in the entire packet is lower for a large packet. I've tried to clarify that... _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Oct 25 19:50:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19646 for ; Mon, 25 Oct 2004 19:50:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEp3-0004gX-35 for rohc-web-archive@ietf.org; Mon, 25 Oct 2004 20:04:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMENw-0006zu-2g; Mon, 25 Oct 2004 19:36:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBfc-0008Pl-Dl for rohc@megatron.ietf.org; Mon, 25 Oct 2004 16:42:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06892 for ; Mon, 25 Oct 2004 16:42:21 -0400 (EDT) Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBt8-0000DD-2Y for rohc@ietf.org; Mon, 25 Oct 2004 16:56:22 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Oct 2004 21:43:03 +0100 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V2Q3RK8V; Mon, 25 Oct 2004 21:43:05 +0100 From: "West, Mark" To: Gorry Fairhurst Date: Mon, 25 Oct 2004 21:41:45 +0100 (GMT Daylight Time) In-Reply-To: Message-ID: References: X-X-Sender: maw1@maw-laptop.comm.ad.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: Gorry Fairhurst , rohc@ietf.org Subject: [rohc] Re: ROHC WGLC (Questions): draft-ietf-rohc-tcp-field-behavior-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Hi Gorry, > I enclose the part of my review contains substantive questions. I have tried > to separate editorial and requests for clarification of text into a separate > list. Thanks again for this review. Some comments on the -04 updates, inline. Hopefully they'll make sense, but I'm sure that you'll shout if I've missed anything..! Cheers, Mark. > *: Page 4: Intro, para 6: > "It is unclear how reserved bits should be handled.." > - I agree there are various options for handling reserved bits, but the text > in this paragraph is weak. IMHO, we MUST expect that these bits may be used > in future revisions of the protocol and it is important that these are > transparently supported - but it is not possible to optimise for cases that > have yet to be defined. > Fair point -- I've updated the text. > *: Page 5: Section 2: > - What is the intended type of document? > - I'd assumed INFO RFC, in which case this terminology is not needed (and > seems not to be used). > - RFC 2119 could also then be removed from the references if this section is > removed (see later note). > I also assume INFO. > *: Page 8: STATIC-KNOWN > "Fragmentation should not be common" > (i) This seems OK, but is it the case that fragmentation is still sometimes > observed in "broken" tunneled architectures (e.g. those that do not handle > PMTUD and/or do not observe the expected rules)? - Thoughts? > (ii) Could you include an RFC reference to PMTUD? > (iii) "should not be common due to" -> "is not expected to be a common in > the Internet" > (iv) The final sentence is not clear to me - can you add text to explain > this? > Fragmentation was also one of Reiner's points. I haven't included a link to the current PMTUD work. However, I have generally overhauled this text. > *: Page 8: Protocol > "This field will usually have the same value in all packets" > - Tunnels and Protocol values: > (i) I thought this was implied in the definition of a "Packet Flow", but > perhaps this is considering the case of tunnels or security extensions? > (ii) Do you assume the set of tunnel encapsulations are always the same for > the lifetime of a single flow? - I was thinking of (e.g.) the use of tunnels > within mobile IP. What would be the implications of additional/removal of > tunnels on the ROHC behaviour? > > *: Page 8: Flags > "It appears unwise to.." > - Can the WG decide whether it is undesirable or acceptable, and update the > text to remove the ambiguity? Oh, it's definitely unwise! Ambiguity removed... > > *: Page 8: Flags > "The alternative coding of CHANGING is suggested..." > - The current text (*suggested*) seems very loose: Is this possible? > - Is it the recommended approach? > It's recommended -- strengthened the text. > *: Page 9: final para > "It is expected tha*n* some additional checksum (such as CRC)..." > - This seems very desirable: I'm surprised that this is not a requirement? > This isn't a requirements' document -- we've got one of them, and I believe that this *is* a requirement. However, I've strengthened the text for the additional checksum. > ***: Page 12: Section 4.1 > - The document says the DF field is not seen as replicable between flows > - This seems acceptable, but why is it NOT possible to replicate this (can > you explain - I don't understand)? > Having reviewed this, I don't understand why it's not *possible* to replicate the field (and have changed the text accordingly). However, the idea of signalling replication (or not) of a 1-bit field is a bit, well, daft. I've added text to this end... > ***: Page 13: Point (1) - DSCP remarking > (i) I think the same "type of traffic" does not mean the same as "traffic > with the same DSCP value" - i.e. traffic with the same diffserv class. > Similar "traffic" could be assigned different DSCP values based on > destination, congestion state, other policies. > > (ii) I'm not clear on the documents guidance here. My understanding was that > DS traffic conditioners could be expected to modify a flow's DSCP value > based on metered flow properties and overall traffic levels. This being so, > then surely the DSCP value may be reasonably expected to change (i.e. be > remarked) between a small number of DSCP values. Passing through multiple > diffserv domains may result in multiple remarkings. There are likely to be > commonalities between the set of DSCPs encountered by different flows > (packet streams) between a pair of end hosts. RFC2475 says: > Yes, remarking could happen. But header compression is done on a point-to-point link, so I'm not sure that we expect too much variability from the different domains. However, I've tried to clarify the text. > > *: Page 17: IP TOS in table > (i) Would it be better to call this DSCP? > (ii) The remarking discussion above raises the question about whether this > is RC or Alternating. - Thoughts? > Having considered this, 'alternating' seems a better choice than rarely-changing. So I've changed it accordingly (it doesn't significantly affect things), as it feels more reasonable. From a profile design perspective, it's likely to be handled the same way regardless of whether the field is RC or alternating. > ***: Page 22: Section 5.2.1 > - The MSS agrees an upper bound, but the actual used value may be different. > The use of PMTUD suggests that actual segment size used may be less than the > segment size that was originally negotiated. Specifically if the segment > size is less than the negotiated MSS, it may be expected that PMTUD > algorithm will probe using a range of segment sizes as a session progresses. > - THOUGHTS & IMPLICATIONS (if any)? Good point -- I've included a reference to PMTU. My 'thought' is that you are right about this. The 'implications', however, are negligible (if any). All we are really thinking about here is the ability to make use of a stable payload size to improve compression. Changes of segment size in active PMTU probing would disrupt this. > > ***: Page 33: Section 5.3.2: final para > - I'd like to see some discussion on what happens when new options do > appear, and what needs to be done! > - Clearly these can not be optimised for... > - Will packets with the new option be discarded (surely not)? > I'd expect these to be transparently forwarded (is there any guidance?) > Any option will always be carried transparently. As you suggest, the only issue is whether or not the conveyance of the option can be optimised. I've added guidance to this end... > *: Page 34: Section 6.3: final para > "will support experimental options" > - Does this mean will be optimised for? > - Does this mean the packet will be discarded (surely not)? > The word support needs clarification, I'd expect these to be transparently > forwarded. > Reiner also picked up on this -- I've tried to be much stricter about the 'supported' and 'optimised for'. One note that I haven't made in the draft, but is a more general comment on the philosophy of header compression: we *never* discard a packet. Worst case is to send the packet as 'uncompressed'. > *: Page 35: Section 6.6: final para > "support for reordering of compressed packets will require" > - Explain where you are referring to: "reordering on the path between the > compressor and decompressor" There is now an excellent draft discussing the support of re-ordering in ROHC profiles. Given this, I've removed this text -- it's superceded by the later work. > > ***: References > - Normative references are always debatable, and I'd like to open this > debate at this stage. > - I'd have definitely expected that TCP standards that this analysis relies > on MUST be normative references. The justification is that these references > *DEFINE* the behaviour that is described, if they are modified by subsequent > RFCs then the conclusions could change - I thought that was what we had > normative references for? > I really wasn't sure about the normative/informative split -- so sincere thanks for the steer! Your suggestion makes sense -- I've taken your split below as a starting point. > - I propose the following are normative to this document: > 1,2,3,4,7,8,9,11,12,16,17,18,24,25,26,27,31,33,38. > > - I suggest the other references provide background, explanation of use, or > examples of mechanisms that require/utilise specific headers. > > - Reference 23 is normative if used, but is an appropriate to this RFC and > should be removed. > Deleted. > - Reference 39 includes a typo - remove ".txt". > Whoops! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 26 04:10:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08637 for ; Tue, 26 Oct 2004 04:10:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMdO-0005E3-5J for rohc-web-archive@ietf.org; Tue, 26 Oct 2004 04:24:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMN5-0004pM-EX; Tue, 26 Oct 2004 04:07:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMJl-0003sv-F3 for rohc@megatron.ietf.org; Tue, 26 Oct 2004 04:04:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08278 for ; Tue, 26 Oct 2004 04:04:31 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMXJ-00057x-8W for rohc@ietf.org; Tue, 26 Oct 2004 04:18:37 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i9Q82qbI014692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Oct 2004 09:02:55 +0100 (BST) Message-ID: <417E04AC.5000504@erg.abdn.ac.uk> Date: Tue, 26 Oct 2004 09:02:52 +0100 From: gorry fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "West, Mark" Subject: Re: [rohc] Re: ROHC WGLC (NiTs): draft-ietf-rohc-tcp-field-behavior-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-ERG-MailScanner-To: gorry@erg.abdn.ac.uk, mark.a.west@roke.co.uk, rohc@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Gorry Fairhurst , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gf@erg.abdn.ac.uk List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit ACK: These changes seem to be good to me. Gorry Fairhurst West, Mark wrote: > Hi Gorry, > > Nothing *too* controversial here (I hope!)... > > I've incorporated updates into the -04 draft and I think that I've > captured all of these. A couple of points, inline. > > Cheers, > > Mark. > > > >>Nit: Page 4: Intro, para 3: >>"A less stable but more detailed analysis is done in section 5..." >>- Perhaps a poor choice of words: if the section is not stable, we should >>not publish as an RFC :-)? >>- Please could you suggest some clearer words to describes the constraints >>in section 5. > > > I have no idea why it says 'less stable', so I took that out :-) > > >>Nit: Page 7: Source and Destination addresses >>- Are we considering possible Tunnel encapsulations at this point? >>- If so, is this referring to the inner-most IP header (directly preceding >>the TCP header)? >> > > > Yes, we are considering tunnel encapsulations -- I've updated the text to > allow for this (the issue of flow separation is something that is, in > part, at the discretion of the compressor). > > < > >>Nit: Page 22: Section 5.2.1 para 7. >>"It would also be desirable to.." >>-> Is the WG confident enough to say: >>"It is desirable to" >> > > > Yes! > > >>NiT: Page 33: Section 6.3: para 1 >>(i) "not that onerous" >>- This text is unclear, in terms of what? >>- Do you mean there are fewer bytes? >>i.e. overhead is less significant (i.e. than 10% of capacity for an MSS of >>536B and less than 3% for 1460B)? >> > > > Yes, I mean that the percentage of header bytes in the entire packet is > lower for a large packet. I've tried to clarify that... > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 26 04:29:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09947 for ; Tue, 26 Oct 2004 04:29:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMvi-0005a8-Fw for rohc-web-archive@ietf.org; Tue, 26 Oct 2004 04:43:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMcf-0007un-Av; Tue, 26 Oct 2004 04:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMMV8-0005nf-8z for rohc@megatron.ietf.org; Tue, 26 Oct 2004 04:16:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08991 for ; Tue, 26 Oct 2004 04:16:13 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMMih-0005JP-TJ for rohc@ietf.org; Tue, 26 Oct 2004 04:30:20 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i9Q8EWOZ014923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Oct 2004 09:14:34 +0100 (BST) Message-ID: <417E0769.5020000@erg.abdn.ac.uk> Date: Tue, 26 Oct 2004 09:14:33 +0100 From: gorry fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "West, Mark" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-ERG-MailScanner-To: gorry@erg.abdn.ac.uk, mark.a.west@roke.co.uk, rohc@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Gorry Fairhurst , rohc@ietf.org Subject: [rohc] Re: ROHC WGLC (Questions): draft-ietf-rohc-tcp-field-behavior-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gf@erg.abdn.ac.uk List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit I think your comments should address my concerns, were there sufficient changes to suggest a revised draft should be issued to the WG? See a few comments in-line. West, Mark wrote: > Hi Gorry, > > >>I enclose the part of my review contains substantive questions. I have tried >>to separate editorial and requests for clarification of text into a separate >>list. > > > Thanks again for this review. Some comments on the -04 updates, inline. > Hopefully they'll make sense, but I'm sure that you'll shout if I've > missed anything..! > > Cheers, > > Mark. > > >>***: Page 13: Point (1) - DSCP remarking >>(i) I think the same "type of traffic" does not mean the same as "traffic >>with the same DSCP value" - i.e. traffic with the same diffserv class. >>Similar "traffic" could be assigned different DSCP values based on >>destination, congestion state, other policies. >> >>(ii) I'm not clear on the documents guidance here. My understanding was that >>DS traffic conditioners could be expected to modify a flow's DSCP value >>based on metered flow properties and overall traffic levels. This being so, >>then surely the DSCP value may be reasonably expected to change (i.e. be >>remarked) between a small number of DSCP values. Passing through multiple >>diffserv domains may result in multiple remarkings. There are likely to be >>commonalities between the set of DSCPs encountered by different flows >>(packet streams) between a pair of end hosts. RFC2475 says: >> > > > Yes, remarking could happen. But header compression is done on a > point-to-point link, so I'm not sure that we expect too much variability > from the different domains. > > However, I've tried to clarify the text. > > Not sure I understand - the way I understood it was that an IP router (edge node in a DS domain) that remarks can remark the DSCP in a packte based on a policy - and/or on the traffic level (using a meter). If it's the latter, then as the traffic conditions vary, the proportion of remarked packets also varies... I don't have any operational experience - so someone who has be able to tell us more about what they would expect. In the absence of evidence otherwise, I'd assume DSCP **can** change within an IP flow. Do other people on the list have more insight? > > >>*: Page 34: Section 6.3: final para >>"will support experimental options" >>- Does this mean will be optimised for? >>- Does this mean the packet will be discarded (surely not)? >>The word support needs clarification, I'd expect these to be transparently >>forwarded. >> > > > Reiner also picked up on this -- I've tried to be much stricter about the > 'supported' and 'optimised for'. > OK - I saw this comment to Reiner's mail. > One note that I haven't made in the draft, but is a more general comment > on the philosophy of header compression: we *never* discard a packet. > Worst case is to send the packet as 'uncompressed'. > Yes - I like this. Gorry. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 26 05:27:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16310 for ; Tue, 26 Oct 2004 05:27:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNpG-0006zE-VU for rohc-web-archive@ietf.org; Tue, 26 Oct 2004 05:41:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNYg-00060y-Mm; Tue, 26 Oct 2004 05:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNPE-0003xE-MN for rohc@megatron.ietf.org; Tue, 26 Oct 2004 05:14:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15282 for ; Tue, 26 Oct 2004 05:14:14 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNcg-0006ka-GW for rohc@ietf.org; Tue, 26 Oct 2004 05:28:22 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9Q9E4R2029568 for ; Tue, 26 Oct 2004 11:14:04 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 11:14:03 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 26 Oct 2004 11:14:00 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'gf@erg.abdn.ac.uk'" , "West, Mark" Subject: RE: [rohc] Re: ROHC WGLC (Questions): draft-ietf-rohc-tcp-field-b ehavior-03.txt Date: Tue, 26 Oct 2004 11:13:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Oct 2004 09:14:04.0004 (UTC) FILETIME=[236DB240:01C4BB3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Gorry Fairhurst , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > I think your comments should address my concerns, were there > sufficient changes to suggest a revised draft should be issued > to the WG? Yes, I've requested a new draft version, which has been submitted. If the folks who had comments are happy with the update, we'll submit that to the IESG. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 26 05:29:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16475 for ; Tue, 26 Oct 2004 05:29:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNr0-00071q-Bh for rohc-web-archive@ietf.org; Tue, 26 Oct 2004 05:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNYj-00063M-BU; Tue, 26 Oct 2004 05:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNPr-00048v-0l for rohc@megatron.ietf.org; Tue, 26 Oct 2004 05:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15455 for ; Tue, 26 Oct 2004 05:14:52 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNdD-0006lk-SK for rohc@ietf.org; Tue, 26 Oct 2004 05:29:00 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9Q9EbfM004879 for ; Tue, 26 Oct 2004 11:14:37 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 11:14:37 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 26 Oct 2004 11:14:37 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Tan Wee Lum'" , rohc@ietf.org Subject: RE: [rohc] Feedback channels in ROHC-TCP Date: Tue, 26 Oct 2004 11:14:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Oct 2004 09:14:37.0334 (UTC) FILETIME=[374B7360:01C4BB3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Satellite links! /L-E > -----Original Message----- > From: Tan Wee Lum [mailto:wltan3@ie.cuhk.edu.hk] > Sent: den 26 oktober 2004 06:07 > To: Lars-Erik Jonsson (LU/EAB); rohc@ietf.org > Subject: RE: [rohc] Feedback channels in ROHC-TCP > > > Hi, > > May I ask what are examples of unidirectional links? > > Thanks, > Wee Lum > > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > > Sent: Thursday, October 21, 2004 10:29 PM > To: 'Tan Wee Lum'; rohc@ietf.org > Subject: RE: [rohc] Feedback channels in ROHC-TCP > > The forward and return flows of a TCP connection might not go over the > same path, and only one of the two might thus go over a link > where HC is > applied (which might be a unidirectional link). > > E2E, there is of course a bidirectional connection for TCP, but HC is > applied on a per-link basis. > > Rgds, > /L-E > > > > -----Original Message----- > > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Tan Wee Lum > Sent: den 21 oktober 2004 08:04 > To: rohc@ietf.org > Subject: [rohc] Feedback channels in ROHC-TCP > > > Hi, > > In the ROHC-TCP draft version 7, it is mentioned in Section 3.1 that > the disadvantage of the full header request mechanism in IPHC > is that it requires a feedback channel that may be unavailable in > some circumstances. > > I am wondering what are the circumstances in which a feedback channel > is not available? I thought that a TCP connection would require a > full-duplex > channel to work? > > Thanks for any clarification. > > Wee Lum > > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 26 10:04:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07132 for ; Tue, 26 Oct 2004 10:04:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSA8-0003jn-H0 for rohc-web-archive@ietf.org; Tue, 26 Oct 2004 10:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMRvZ-0005Da-UJ; Tue, 26 Oct 2004 10:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDfE-00033v-DQ for rohc@megatron.ietf.org; Mon, 25 Oct 2004 18:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05817 for ; Mon, 25 Oct 2004 18:50:05 -0400 (EDT) Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDsl-0000CJ-KP for rohc@ietf.org; Mon, 25 Oct 2004 19:04:08 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i9PMnEQ4021507 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 25 Oct 2004 18:49:14 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.11/8.12.10) with ESMTP id i9PMnDAm005613; Mon, 25 Oct 2004 18:49:13 -0400 Date: Mon, 25 Oct 2004 18:49:13 -0400 (EDT) From: Matt Mathis To: "West, Mark" In-Reply-To: Message-ID: References: <6.1.1.1.1.20040913133004.02908e68@imap.eed.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer1.psc.edu X-Virus-Status: Clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mailer1.psc.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Tue, 26 Oct 2004 10:03:55 -0400 Cc: "Gorry Fairhurst \(E-mail\)" , "'rohc@ietf.org'" , Reiner Ludwig , "Lars-Erik Jonsson \(LU/EAB\)" , "'Carsten Bormann \(E-mail\)'" , "Kristofer Sandlund \(E-mail\)" , "Ghyslain Pelletier \(LU/EAB\)" , Mark Allman Subject: [rohc] Re: WG last-call for draft-ietf-rohc-tcp-field-behavior-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f I think I weighed in on this earlier - I like "fragmentation is generally not expected" because it is somewhat vague. Making it less vague requires explaining all of the caveats. In the end they all boil down to "our assumptions hurt the performance of people who are doing things in non-optimal ways (e.g. using fragmentation at all with TCP), but without effecting their interoperation." Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- On Mon, 25 Oct 2004, West, Mark wrote: > > Hi Reiner, all, > > > > > Sorry for being late ... > > Given the time it's taken me to get around to incorporating these, I think > I'm the one who should be apologising..! > > > > > I think this document is ready to go! > > > > Some minor comments: > > -------------------- > > > > - Section 3.1.2 discusses IPv4 header fields and this statement caught my attention: > > "The More Fragments (MF) flag is expected to be zero because > > fragmentation is generally not expected." Is this a reasonable > > assumption? I have added Matt Mathis to the cc: of this mail, and would > > like to hear from him what he thinks. Since Matt has done a lot of work > > on PMTU discovery, I'm sure that he knows about these things. > > > > I've weakened the text -- it seems that 'generally not expected' is a > slightly optimistic view! Anyway, the point is that this is not, perhaps, > too important: if you have a fragmented packet then there are two > consequences... (i) the fragment containing the TCP header is probably > comparatively large, so if compression is not optimal it's not a big deal; > and (ii) the TCP profile won't be used to compress subsequent fragments > (because there's no TCP header). > > Plus, I seem to recall that Matt isn't a great fan of fragmentation -- and > having a compression profile that does not encourage fragmentation seems > to be reasonable! > > > - Section 3.1.2, bullet "o Protocol": It seems that the text under this > > bullet is a copy/paste from a previous bullet (IPv6/NextHeader). > > Probably the wording should be different. > > Whoops! Updated... > > > > > - Section 4.3: > > "(1) On the server side, the port number is likely to be a well-known > > value. On the client side, the port number is generally selected > > by the stack automatically. Whether the port number is replicable > > depends upon how the stack chooses the port number. However, most > > implementations use a simple scheme which sequentially picks the > > next available port number. This is clearly exploitable in a > > compression scheme." If I understand the recent discussions about > > "reset attacks" in the TCPM WG correctly, I'm not sure whether > > implementers should be encouraged to rely on the fact that clients > > simply sequentially pick the next available port number. I suggest > > asking Mark Allman about this one. > > > > I guess the jury's still out on the solution to blind reset -- however, > I've changed the text anyway to suggest that relying on / exploiting this > assumption about behavior may be fragile (in that, like the ISS, this > behavior may change) > > > - Section 5.2.1: > > "The Nagle algorithm is an optimisation and not required to be used." > > RFC1122 says that a TCP SHOULD implement Nagle, and as far as I know it > > is turned on by default in all common TCP implementations. > > > > Recent personal experience has indeed confirmed that Nagle is turned on by > default! I've updated the text accordingly... > > > - Section 5.3.2 discusses various options and for some options, e.g., > > POC and T/TCP, and concludes that in practice these options are never > > seen. Why then is it a requirement that "the header compression scheme > > should be able to encode it"? > > > > The wording of this (something that Gorry also picked up on) is far too > sloppy. I've tried to be stricter about the concepts of 'supporting' > [should be able to handle anything] and 'optimised for' [no point in > optimising rare cases]. > > In this case, there's no requirement for 'optimal' treatment; but it must > be possible to carry all options. > > > - Section 5.3.2, last paragraph: > > "In the discussion above regarding timestamps it is pointed out that > > there is the possibility (at some time in the future) of negotiations > > being permitted more generally than in the SYN packets at connection > > set-up. Although there seems to be no compelling need to optimise > > for this, it is worth pointing out that the compression scheme should > > be able to cope with arbitrary options appearing at any point within > > the flow." I don't recall any such proposal in the transport area, > > and I don't understand why this last recommendation is made. Again, I > > suggest asking Mark Allman about this one. > > > > We kicked this one around a bit, shortly after these comments were > circulated. I think that our conclusion was that there *had* been some > discussion along these lines, but it was perhaps not appropriate to put > this text in. > > The draft now just makes more general statements about not assuming where > options may occur. Hopefully this is more generic and captures the spirit > of what matters with regard to header compression. It incidentally > encompasses the idea that timestamps could, conceivably, start/stop > mid-flow. > > > I will send a few editing nits directly to the authors. > > > > ///Reiner > > > > Cheers, > > Mark. > > -- > > Visit our website at www.roke.co.uk > > Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 26 10:07:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07403 for ; Tue, 26 Oct 2004 10:07:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSCe-0003mH-2c for rohc-web-archive@ietf.org; Tue, 26 Oct 2004 10:21:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMRva-0005Dy-8E; Tue, 26 Oct 2004 10:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIcB-0006Tw-HU for rohc@megatron.ietf.org; Tue, 26 Oct 2004 00:07:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08963 for ; Tue, 26 Oct 2004 00:07:15 -0400 (EDT) Received: from eng.ie.cuhk.edu.hk ([137.189.96.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIpa-00016i-Da for rohc@ietf.org; Tue, 26 Oct 2004 00:21:21 -0400 Received: from viruswall2.ie.cuhk.edu.hk (viruswall2 [137.189.96.53]) by eng.ie.cuhk.edu.hk (8.12.10/8.12.10) with ESMTP id i9Q472dZ010567 for ; Tue, 26 Oct 2004 12:07:03 +0800 (HKT) Received: from 825pc13 (iegatea1.ie.cuhk.edu.hk [137.189.98.1]) by viruswall2.ie.cuhk.edu.hk (8.12.10/8.12.10) with ESMTP id i9Q471s4002694; Tue, 26 Oct 2004 12:07:01 +0800 From: "Tan Wee Lum" To: "'Lars-Erik Jonsson \(LU/EAB\)'" , Subject: RE: [rohc] Feedback channels in ROHC-TCP Date: Tue, 26 Oct 2004 12:07:14 +0800 Message-ID: <000001c4bb11$46b1ebc0$443aa8c0@825pc13> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 26 Oct 2004 10:03:55 -0400 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Hi, May I ask what are examples of unidirectional links? Thanks, Wee Lum -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: Thursday, October 21, 2004 10:29 PM To: 'Tan Wee Lum'; rohc@ietf.org Subject: RE: [rohc] Feedback channels in ROHC-TCP The forward and return flows of a TCP connection might not go over the same path, and only one of the two might thus go over a link where HC is applied (which might be a unidirectional link). E2E, there is of course a bidirectional connection for TCP, but HC is applied on a per-link basis. Rgds, /L-E > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of > Tan Wee Lum > Sent: den 21 oktober 2004 08:04 > To: rohc@ietf.org > Subject: [rohc] Feedback channels in ROHC-TCP > > > Hi, > > In the ROHC-TCP draft version 7, it is mentioned in Section 3.1 that > the disadvantage of the full header request mechanism in IPHC > is that it requires a feedback channel that may be unavailable in > some circumstances. > > I am wondering what are the circumstances in which a feedback channel > is not available? I thought that a TCP connection would require a > full-duplex > channel to work? > > Thanks for any clarification. > > Wee Lum > > > > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Oct 26 19:48:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01603 for ; Tue, 26 Oct 2004 19:48:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbGs-0003Zz-7I for rohc-web-archive@ietf.org; Tue, 26 Oct 2004 20:02:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZ1t-0005k1-BL; Tue, 26 Oct 2004 17:38:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYRz-0000Qp-V3; Tue, 26 Oct 2004 17:01:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20776; Tue, 26 Oct 2004 17:01:49 -0400 (EDT) Message-Id: <200410262101.RAA20776@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 17:01:49 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-08.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : ROHC Implementer's Guide Author(s) : L. Jonsson, P. Kremer Filename : draft-ietf-rohc-rtp-impl-guide-08.txt Pages : 21 Date : 2004-10-26 This document describes common misinterpretations and some ambiguous points of ROHC [1], which defines the framework and four profiles of a robust and efficient header compression scheme. The members of the ROHC working group have identified these issues during implementation and at the various interoperability test events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-rtp-impl-guide-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26161152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26161152.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Thu Oct 28 06:58:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29821 for ; Thu, 28 Oct 2004 06:58:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN8Dg-0006La-EE for rohc-web-archive@ietf.org; Thu, 28 Oct 2004 07:13:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7yS-00029c-9D; Thu, 28 Oct 2004 06:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7uW-0001gm-4O for rohc@megatron.ietf.org; Thu, 28 Oct 2004 06:53:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29562 for ; Thu, 28 Oct 2004 06:53:38 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN88P-0006Gi-KV for rohc@ietf.org; Thu, 28 Oct 2004 07:08:12 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9SArNkS010364; Thu, 28 Oct 2004 12:53:25 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <962488AE-28CF-11D9-9B35-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Thu, 28 Oct 2004 12:53:22 +0200 To: "'rohc@ietf.org'" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Carsten Bormann Subject: [rohc] Two stranded Internet-Drafts now at http://www.dmn.tzi.org/ietf/rohc/ X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit ROHCers, we managed to make a mess of the submission of two drafts in two different ways (one XML problem that led to the wrong boilerplate, one 2-minute mail delay). As these are important documents that we need to discuss in Washington, I have made them available at the secondary ROHC website: http://www.dmn.tzi.org/ietf/rohc/ Please add these documents to your reading list for the ROHC meeting as you would if they were actual Internet-Drafts. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Oct 28 14:38:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11731 for ; Thu, 28 Oct 2004 14:38:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNFOB-0002yW-3Q for rohc-web-archive@ietf.org; Thu, 28 Oct 2004 14:52:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCmK-0005Sr-7D; Thu, 28 Oct 2004 12:05:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBrI-0007SF-1H; Thu, 28 Oct 2004 11:06:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22467; Thu, 28 Oct 2004 11:06:35 -0400 (EDT) Message-Id: <200410281506.LAA22467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 11:06:35 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-tcp-08.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC): Profile for TCP/IP (ROHC-TCP) Author(s) : G. Pelletier, et al. Filename : draft-ietf-rohc-tcp-08.txt Pages : 84 Date : 2004-10-27 This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-tcp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-tcp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-tcp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-tcp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110239.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Thu Oct 28 14:41:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12280 for ; Thu, 28 Oct 2004 14:41:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNFQy-00039q-S1 for rohc-web-archive@ietf.org; Thu, 28 Oct 2004 14:55:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCmM-0005Uy-RY; Thu, 28 Oct 2004 12:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBrQ-0007Xy-T1; Thu, 28 Oct 2004 11:06:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22489; Thu, 28 Oct 2004 11:06:43 -0400 (EDT) Message-Id: <200410281506.LAA22489@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 11:06:43 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-tcp-field-behavior-04.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : TCP/IP Field Behavior Author(s) : M. West, S. McCanne Filename : draft-ietf-rohc-tcp-field-behavior-04.txt Pages : 42 Date : 2004-10-27 Header compression is possible thanks to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095 [36]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-field-behavior-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-tcp-field-behavior-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-tcp-field-behavior-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-tcp-field-behavior-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-tcp-field-behavior-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110245.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Thu Oct 28 21:39:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13199 for ; Thu, 28 Oct 2004 21:39:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNLyH-0005it-O3 for rohc-web-archive@ietf.org; Thu, 28 Oct 2004 21:54:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJD0-000645-CI; Thu, 28 Oct 2004 18:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGO5-0001vV-5P; Thu, 28 Oct 2004 15:56:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28872; Thu, 28 Oct 2004 15:56:43 -0400 (EDT) Message-Id: <200410281956.PAA28872@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 15:56:43 -0400 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-formal-notation-04.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Formal Notation for Robust Header Compression (ROHC-FN) Author(s) : R. Price, et al. Filename : draft-ietf-rohc-formal-notation-04.txt Pages : 57 Date : 2004-10-28 This document defines ROHC-FN: a formal notation for specifying how to compress and decompress fields from an arbitrary protocol stack. ROHC-FN is intended to simplify the creation of new compression profiles to fit within the ROHC [RFC-3095] framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-formal-notation-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-formal-notation-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-formal-notation-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28155213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-formal-notation-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-formal-notation-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28155213.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Fri Oct 29 02:30:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28454 for ; Fri, 29 Oct 2004 02:30:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQVb-0006PI-5X for rohc-web-archive@ietf.org; Fri, 29 Oct 2004 02:45:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQBM-0007SZ-5d; Fri, 29 Oct 2004 02:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQ47-0007lh-Bw for rohc@megatron.ietf.org; Fri, 29 Oct 2004 02:16:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27196 for ; Fri, 29 Oct 2004 02:16:45 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQIJ-0006Cc-HC for rohc@ietf.org; Fri, 29 Oct 2004 02:31:29 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9T6GXP6029845; Fri, 29 Oct 2004 08:16:35 +0200 (MEST) In-Reply-To: <962488AE-28CF-11D9-9B35-000A95DC4DB6@tzi.org> References: <962488AE-28CF-11D9-9B35-000A95DC4DB6@tzi.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <14799FFC-2972-11D9-9B35-000A95DC4DB6@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Fri, 29 Oct 2004 08:16:33 +0200 To: Carsten Bormann X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "'rohc@ietf.org'" , "Lars-Erik Jonsson \(LU/EAB\)" Subject: [rohc] Internet-Draft reading list now at http://www.dmn.tzi.org/ietf/rohc/, agenda X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit ROHCers, I have put up a reading list for the impending meeting at the secondary ROHC site, http://www.dmn.tzi.org/ietf/rohc/ (I did this list before my second cup of coffee, so please tell me if I'm missing something). The two drafts that were thought lost have now finally turned up in the I-D archives, by the way. We now need to fix the agenda. I expect everything that is not at the RFC editor queue level to be an agenda item. We do need estimations from submitters/presenters as to how much discussion time (including any presentations) we need. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Sat Oct 30 06:49:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14591 for ; Sat, 30 Oct 2004 06:49:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNr2L-0007tk-Kb for rohc-web-archive@ietf.org; Sat, 30 Oct 2004 07:04:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNqiA-0004gA-69; Sat, 30 Oct 2004 06:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNqYM-0001ct-Rg for rohc@megatron.ietf.org; Sat, 30 Oct 2004 06:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13916 for ; Sat, 30 Oct 2004 06:33:44 -0400 (EDT) Received: from bay8-f68.bay8.hotmail.com ([64.4.27.68] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNqme-0007gl-RS for rohc@ietf.org; Sat, 30 Oct 2004 06:48:44 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Oct 2004 03:33:03 -0700 Received: from 212.181.86.195 by by8fd.bay8.hotmail.msn.com with HTTP; Sat, 30 Oct 2004 10:32:09 GMT X-Originating-IP: [212.181.86.195] X-Originating-Email: [gustav_kung@hotmail.com] X-Sender: gustav_kung@hotmail.com From: "Gustav E" To: rohc@ietf.org Date: Sat, 30 Oct 2004 12:32:09 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Oct 2004 10:33:03.0707 (UTC) FILETIME=[D629FAB0:01C4BE6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [rohc] SigComp question: UDVM Compiler? X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi All, Perhaps this might seem as a somewhat off-topic question in this forum: I'm looking for a UDVM-code to bytecode compiler. Does anyone know if such a tool is publicly available somewhere? Just don't want to re-invent the wheel ;-) BR, /Gustav E _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.com/ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc