Re: [Crisp] Nit in lwz-05

Andrew Newton <andy@hxr.us> Thu, 27 April 2006 13:35 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6eI-0006rD-4j; Thu, 27 Apr 2006 09:35:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6dL-0006JB-IQ for crisp@ietf.org; Thu, 27 Apr 2006 09:34:15 -0400
Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ6OY-0004HC-OM for crisp@ietf.org; Thu, 27 Apr 2006 09:18:58 -0400
Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Thu, 27 Apr 2006 09:17:52 -0400 id 015880FD.4450C480.000061A7
In-Reply-To: <OFDEFAF1FD.0255A67E-ONC125715C.002BA649-C125715C.002D12AA@notes.denic.de>
References: <OFDEFAF1FD.0255A67E-ONC125715C.002BA649-C125715C.002D12AA@notes.denic.de>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <8C57A05C-D5E7-4D00-B297-DAFF75C74323@hxr.us>
Content-Transfer-Encoding: 7bit
From: Andrew Newton <andy@hxr.us>
Subject: Re: [Crisp] Nit in lwz-05
Date: Thu, 27 Apr 2006 09:18:56 -0400
To: Marcos Sanz/Denic <sanz@denic.de>
X-Mailer: Apple Mail (2.749.3)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: crisp@ietf.org
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Errors-To: crisp-bounces@ietf.org

On Apr 26, 2006, at 4:12 AM, Marcos Sanz/Denic wrote:

> Fred,
>
>> For requests the range is "6..261", but for responses the value is 3.
>>
>> So "6..261" would invalidate any response.
>>
>> If possible the more correct version would be [ 3 or 6..261 ]
>
> You are right, but what about parenthesizing a bit so that it's clear
> lengths 4 and 5 are forbidden:
>
> 3 or [6..261]
>
> The "problem" now is that no other range in the document has square
> brackets...

How about?

3 or 6..261 *

* In request packets, the payload descriptor can vary in length from  
6 to 261 octets (i.e. 6..261).  In response packets, the payload  
descriptor is always 3 octets.

-andy

_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp