[Rfid] SLRRP Vendor Extensions
Peter Spreadborough <pspreadborough@revasystems.com> Wed, 20 July 2005 22:44 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNIP-0000GE-Hm; Wed, 20 Jul 2005 18:44:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNIN-0000Fg-U2 for rfid@megatron.ietf.org; Wed, 20 Jul 2005 18:44:08 -0400
Received: from charles.revasystems.com (charles.revasystems.com [65.209.89.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05312 for <rfid@lists.ietf.org>; Wed, 20 Jul 2005 18:44:04 -0400 (EDT)
Received: from [192.168.1.50] (avon [192.168.1.50]) by charles.revasystems.com (Postfix) with ESMTP id 2CAE53BE90 for <rfid@lists.ietf.org>; Wed, 20 Jul 2005 18:43:36 -0400 (EDT)
From: Peter Spreadborough <pspreadborough@revasystems.com>
To: rfid@ietf.org
Content-Type: text/plain
Message-Id: <1121899416.21285.235.camel@mad>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2)
Date: Wed, 20 Jul 2005 18:43:36 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Cc:
Subject: [Rfid] SLRRP Vendor Extensions
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Control and Access of Infrastructure for RFID Operations Discussion List <rfid.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rfid>
List-Post: <mailto:rfid@lists.ietf.org>
List-Help: <mailto:rfid-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=subscribe>
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org
To facilitate the support of vendor specific extensions, prior to formal
inclusion into the protocol, the following solution is proposed:
1. The SLRRP message header will be extended to include a thirty two bit
vendor ID field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Message Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. For SLRRP parameters a bit from the "user" bits will be assigned as
the Vendor or V bit.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |V|User | Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Parameter Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. A block of unused message types will be reserved for vendor
extensions.
4. A block of parameter types will be reserved for vendor extensions.
SLRRP implementations may choose to ignore:
- Any message types that fall in to the vendor extension range.
- Any parameter types that fall into the vendor extension range.
- Any parameters that have the V bit set.
If the V bit is set in a parameter header then the vendor ID used in the
encapsulating message will apply. The parameter may then be accepted or
ignored based on the vendor ID. This applies to both defined message
types and extended message types.
_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid
- [Rfid] SLRRP Vendor Extensions Peter Spreadborough
- Re: [Rfid] SLRRP Vendor Extensions Margaret Wasserman
- FW: [Rfid] SLRRP Vendor Extensions Suresh Bhaskaran
- Re: FW: [Rfid] SLRRP Vendor Extensions Peter Spreadborough
- Re: FW: [Rfid] SLRRP Vendor Extensions Margaret Wasserman