From rfid-bounces@lists.ietf.org Tue Jun 07 17:17:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DflRf-00021C-G9; Tue, 07 Jun 2005 17:17:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DflRe-000217-RG
	for rfid@megatron.ietf.org; Tue, 07 Jun 2005 17:17:10 -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 RAA14676
	for <rfid@ietf.org>; Tue, 7 Jun 2005 17:17:08 -0400 (EDT)
Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dflml-0000zc-R1
	for rfid@ietf.org; Tue, 07 Jun 2005 17:39:01 -0400
Received: from [192.168.1.44] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms
	with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Jun 2005 17:16:55 -0400
From: "P. Krishna" <pkrishna@revasystems.com>
To: rfid@ietf.org
Content-Type: text/plain
Message-Id: <1118179013.29438.487.camel@indus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Tue, 07 Jun 2005 17:16:53 -0400
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Jun 2005 21:16:55.0402 (UTC)
	FILETIME=[3B53D4A0:01C56BA6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [Rfid] Ver 02 of the draft
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

Here is the link to the draft:
http://www.ietf.org/internet-drafts/draft-krishna-slrrp-02.txt

For your convenience, I'm also attaching the changelist from ver 01 of
the draft.

Thanks,
Krishna

----- Changelist -----
Based on feedback and suggestions from SLRRP developers, here are 
the changes made in Rev 02 of the draft:

1) Thanks to Suresh Bhaskaran of Intelleflex for pointing out a bug in
the Target Tag parameter in an access command. I've made changes in both
C1G2 Target Tag Parameter and the C1G1 Target Tag parameters. 

2) Changed the following parameters so that they dont have repeating
array of complex types. Nested parameters are okay. This makes parameter
parsing simple. An array is now encoded by sending multiple instances of
the parameter.

- Network interface parameter: It used to have a repeating array of 
<Mode, Power requirement>. Changed it to send only one mode at a time.
                                       
- Antenna configuration parameter: It used to have a repeating array of
<Antenna ID, Antenna type, Gain>. Changed it to contain only one antenna
at a time. 
                                                           
- Frequency Hop Tables Parameter: It used to have a repeating array of
<FhSeqId, #of hops, {frequencies}>. Changed it to contain only one hop
sequence at a time.

- EPC C1G2 Filter parameter: It used to have repeating array of filter
Specs which contained <truncate bit, Action, Memory bank, pointer, Mask
length, Mask>. Changed it to contain only one filter spec at a time.

                                                               
3) Changed the Inventory operation timing parameter:
- We had a notion of start round # and end round # for which the
parameters are to be used; instead we have simplified it to just # of
rounds.                                                                                                                                        

4) Clarifications:
- Its made clear that only the timing parameter is mandatory in the
Inventory command parameter block. The other parameters namely, Filter
parameter, RF parameter and singulation parameters are optional.
                                                                       
- When a stop_access command is sent, when does the removed access-spec
stop taking effect.
                                                                                                                                                             - Page 5: Removed functions that are not instrumented or controlled by SLRRP protocol (e.g., configuration, discovery). These are captured in the Working Group charter and will be tackled by other protocols.                                                                                                                     

5) Added parameter definitions for the inventory access report
- Inventory and Access Report Parameter: Section 3.5.6.1
- Inventory and Access Data Parameter: Section 3.5.6.2
- Tag Data Parameter: Section 3.5.6.3

-------------------------------------------------


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Wed Jun 15 08:38:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiXAD-0003LH-5c; Wed, 15 Jun 2005 08:38:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXAB-0003LC-1n
	for rfid@megatron.ietf.org; Wed, 15 Jun 2005 08:38:35 -0400
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10123
	for <rfid@lists.ietf.org>; Wed, 15 Jun 2005 08:38:33 -0400 (EDT)
Received: by wproxy.gmail.com with SMTP id 69so1725455wra
	for <rfid@lists.ietf.org>; Wed, 15 Jun 2005 05:38:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=snpigdWMS1oHNyDUFOw54rMK/LMsD/XJlHOVBAIN65bmtmfpHsnFkam+A3oZSfRMY30leuo8thJ3xMMH/llpTcBwscxGZdk6PcIRDtJPodV4qwduUeIlefIj3J9Eh547ldrUh6KdVKBJqJZihGIAIjwpH/VFfGTlLLyDYmjHxJA=
Received: by 10.54.40.43 with SMTP id n43mr1955948wrn;
	Wed, 15 Jun 2005 05:38:03 -0700 (PDT)
Received: by 10.54.83.4 with HTTP; Wed, 15 Jun 2005 05:38:03 -0700 (PDT)
Message-ID: <3e7aae3050615053857b53eca@mail.gmail.com>
Date: Wed, 15 Jun 2005 18:08:03 +0530
From: Ramya Desai <ramya.desai@gmail.com>
To: rfid@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Rfid] Frequency Hopping.
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Ramya Desai <ramya.desai@gmail.com>
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

Dear all,
I am new to this group.
I am very confused about the protocol used in frequency hopping to
have synchronization and acquisition.
Where can I get the related document to develop my RFID stack ?

Thanks and regards,
Ramya

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Wed Jun 15 11:21:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DiZhf-0006y4-RZ; Wed, 15 Jun 2005 11:21:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DiZhe-0006xv-RU
	for rfid@megatron.ietf.org; Wed, 15 Jun 2005 11:21:18 -0400
Received: from mse3fe2.mse3.exchange.ms (mse3fe2.mse3.exchange.ms
	[69.25.50.167]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25992
	for <rfid@lists.ietf.org>; Wed, 15 Jun 2005 11:21:15 -0400 (EDT)
Received: from Laptop1.revasystems.com ([157.130.221.86]) by
	mse3fe2.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 15 Jun 2005 11:20:46 -0400
Date: Wed, 15 Jun 2005 11:20:32 -0400
From: "Jeffrey Fischer" <jfischer@revasystems.com>
Subject: Re: [Rfid] Frequency Hopping.
To: rfid@ietf.org
Message-ID: <42B04740.6020408@revasystems.com>
X-Mailer: AOL Communicator (20030919.3 Win)
Organization: REVA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-OriginalArrivalTime: 15 Jun 2005 15:20:47.0034 (UTC)
	FILETIME=[CE17A1A0:01C571BD]
Cc: 
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jfischer@revasystems.com
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


Hi Ramya,

Frequency hopping in RFID is different than frequency hopping in other
types of radio systems, because the tag does not generate a carrier of
its own.  It only echoes the one that the reader uses to interrogate it
with.  As a result. there is no synchronization or acquisition of the
carrier as there would be in a conventional frequency hopping system.

Furthermore, there is not even a need to specify what that carrier is if
you have a single reader in a system.  The only reason to actually
create a frequency plan is to prevent the transmit signal from multiple
readers from stepping on each others receive signals.

If you have specific questions regarding your development, I would be
happy to try to field them.

Jeff Fischer
Reva Systems
100 Apollo Dr.
Chelmsford, MA 01824
Desk: 978-244-0010 x205
Cell:   617-823-2560

Ramya Desai wrote on 6/15/2005, 8:38 AM:

  > Dear all,
  > I am new to this group.
  > I am very confused about the protocol used in frequency hopping to
  > have synchronization and acquisition.
  > Where can I get the related document to develop my RFID stack ?
  >
  > Thanks and regards,
  > Ramya
  >
  > _______________________________________________
  > Rfid mailing list
  > Rfid@lists.ietf.org
  > https://www1.ietf.org/mailman/listinfo/rfid
  >

-- 





_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Fri Jun 24 16:25:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dluk9-000753-L5; Fri, 24 Jun 2005 16:25:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dluk8-00074y-UZ
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 16:25:40 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21696
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 16:25:38 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLQ8>; Fri, 24 Jun 2005 15:25:24 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E0388@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 15:25:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] draft-krishna-slrrp-02: Triggers
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>
Content-Type: multipart/mixed; boundary="===============1413441788=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============1413441788==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C578FA.D6C4E634"

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_01C578FA.D6C4E634
Content-Type: text/plain

In addition to supporting one or more RFID air-protocols, an RFID reader may
digital input ports that can be wired to the output of sensors such as
motion detectors.  Does SLRRP provide a mechanism to associate a digital
input port as a triggering mechanism either to initiate a read-cycle or to
initiate report generation?
 
Sections 3.4.14 and 3.5.6.1 mention triggers.  Only in 3.5.6.1 does there
appear to be a specific definition of a trigger and that is only a "timer".
 
Rob Buck
 
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C578FA.D6C4E634
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D0.E381C330">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>In addition to supporting one or =
more RFID
air-protocols, an RFID reader may digital input ports that can be wired =
to the
output of sensors such as motion detectors. <span
style=3D'mso-spacerun:yes'>&nbsp;</span>Does SLRRP provide a mechanism =
to
associate a digital input port as a triggering mechanism either to =
initiate a
read-cycle or to initiate report =
generation?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Sections 3.4.14 and 3.5.6.1 =
mention
triggers.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Only in 3.5.6.1 =
does
there appear to be a specific definition of a trigger and that is only =
a "timer".<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob =
Buck</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C578FA.D6C4E634--


--===============1413441788==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1413441788==--




From rfid-bounces@lists.ietf.org Fri Jun 24 16:29:22 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dluni-0004Rf-73; Fri, 24 Jun 2005 16:29:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlung-0004Ra-8V
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 16:29:20 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22181
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 16:29:18 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLRK>; Fri, 24 Jun 2005 15:29:04 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E0389@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 15:28:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] draft-krishna-slrrp-02: Data "smoothing"
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>
Content-Type: multipart/mixed; boundary="===============0483232238=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============0483232238==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C578FB.073047FA"

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_01C578FB.073047FA
Content-Type: text/plain

Does SLRRP provide a mechanism for "smoothing" RFID data - i.e., eliminating
duplicate reads?  If not, is there no concern about unnecessary network
traffic transmitting a significant amount of redundant data?
 
Rob
 
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C578FB.073047FA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D1.644C30E0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Does SLRRP provide a mechanism for =
"smoothing"
RFID data - i.e., eliminating duplicate reads? <span
style=3D'mso-spacerun:yes'>&nbsp;</span>If not, is there no concern =
about unnecessary
network traffic transmitting a significant amount of redundant =
data?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob</span></font><=
o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C578FB.073047FA--


--===============0483232238==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0483232238==--




From rfid-bounces@lists.ietf.org Fri Jun 24 16:50:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dlv85-00016m-WD; Fri, 24 Jun 2005 16: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 1Dlv82-00016h-4j
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 16:50:22 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23886
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 16:50:19 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLSY>; Fri, 24 Jun 2005 15:50:06 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E038B@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 15:50:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] draft-krishna-slrrp-02: no serial device support?
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>
Content-Type: multipart/mixed; boundary="===============0908190149=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============0908190149==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C578FE.4C1F2324"

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_01C578FE.4C1F2324
Content-Type: text/plain

SLRRP is a network protocol.  Is it safe to say that SLRRP does not apply to
low-end, serial readers?  Was there any consideration given to non-network
readers?
 
Rob
 
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C578FE.4C1F2324
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D4.598DC3F0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>SLRRP is a network protocol. <span
style=3D'mso-spacerun:yes'>&nbsp;</span>Is it safe to say that SLRRP =
does not
apply to low-end, serial readers? <span =
style=3D'mso-spacerun:yes'>&nbsp;</span>Was
there any consideration given to non-network =
readers?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob</span></font><=
o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C578FE.4C1F2324--


--===============0908190149==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0908190149==--




From rfid-bounces@lists.ietf.org Fri Jun 24 16:55:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlvDA-0002AM-25; Fri, 24 Jun 2005 16:55:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvD3-00027A-Pf
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 16:55:37 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24140
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 16:55:29 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLS8>; Fri, 24 Jun 2005 15:55:16 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E038C@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 15:55:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] RE: draft-krishna-slrrp-02: SLRRP RNC API?
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>
Content-Type: multipart/mixed; boundary="===============0266742384=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============0266742384==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C578FF.04EEEB8C"

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_01C578FF.04EEEB8C
Content-Type: text/plain

Is there any plan to standardize an API for the RNC side of SLRRP?
 
Rob Buck
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C578FF.04EEEB8C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D5.1262D000">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Is there any plan to standardize =
an API
for the RNC side of SLRRP?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob =
Buck</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C578FF.04EEEB8C--


--===============0266742384==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0266742384==--




From rfid-bounces@lists.ietf.org Fri Jun 24 17:00:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlvHp-0003VR-9C; Fri, 24 Jun 2005 17:00:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvHj-0003T2-E5
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 17:00:23 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24610
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 17:00:21 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLTG>; Fri, 24 Jun 2005 16:00:07 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E038E@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 16:00:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] RE: draft-krishna-slrrp-02: Are Access Commands Batched?
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>
Content-Type: multipart/mixed; boundary="===============1280494861=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============1280494861==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C578FF.B2219F8E"

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_01C578FF.B2219F8E
Content-Type: text/plain

Each Access command defines an operation such as Read, Write, Kill, etc.
Does the reader effectively batch these commands and execute them only after
receiving an inventory command?  If so, what's the need for 3.4.11
STOP_ACCESS?  Executing an access command should be instantaneous.
 
Rob Buck
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C578FF.B2219F8E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D5.BF953100">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Each Access
command defines an operation such as Read, Write, Kill, etc.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Does the reader effectively =
batch these
commands and execute them only after receiving an inventory =
command?<span
style=3D'mso-spacerun:yes'>&nbsp; </span><span class=3DGramE>If so, =
what's the need
for 3.4.11 STOP_ACCESS?</span><span style=3D'mso-spacerun:yes'>&nbsp;
</span>Executing an access command should be =
instantaneous.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob =
Buck</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C578FF.B2219F8E--


--===============1280494861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1280494861==--




From rfid-bounces@lists.ietf.org Fri Jun 24 17:02:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlvJM-0004B1-6M; Fri, 24 Jun 2005 17:02:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvJK-000497-BI
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 17:02:02 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24764
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 17:01:59 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLTJ>; Fri, 24 Jun 2005 16:01:46 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E038F@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 16:01:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] draft-krishna-slrrp-02: Access Command Target Tag Parameters?
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>
Content-Type: multipart/mixed; boundary="===============0333994243=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============0333994243==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C578FF.D9039954"

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_01C578FF.D9039954
Content-Type: text/plain

Regarding section 3.5.5.1.2.3.   Each access command pairs a set of target
tag parms with a set of operations parms?  The target tag parms define a tag
population that the set of operations are performed on?
 
Rob Buck
 
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C578FF.D9039954
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D5.F7EBF390">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Regarding section 3.5.5.1.2.3.<span
style=3D'mso-spacerun:yes'>&nbsp; </span><span
style=3D'mso-spacerun:yes'>&nbsp;</span><span class=3DGramE>Each</span> =
access
command pairs a set of target tag <span class=3DSpellE>parms</span> =
with a set of
operations <span class=3DSpellE>parms</span>?<span
style=3D'mso-spacerun:yes'>&nbsp; </span>The target tag <span =
class=3DSpellE>parms</span>
define a tag population that the set of operations are performed =
on?<font
color=3Dblue><span =
style=3D'color:blue'><o:p></o:p></span></font></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob =
Buck</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C578FF.D9039954--


--===============0333994243==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0333994243==--




From rfid-bounces@lists.ietf.org Fri Jun 24 17:08:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlvPf-0005of-5e; Fri, 24 Jun 2005 17:08:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvPd-0005nq-GO
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 17:08:33 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25233
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 17:08:31 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLTS>; Fri, 24 Jun 2005 16:08:17 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E0390@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 16:08:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] draft-krishna-slrrp-02: Access Command to Inventory EPC's
	only
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>
Content-Type: multipart/mixed; boundary="===============2139753522=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============2139753522==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57900.D49539BC"

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_01C57900.D49539BC
Content-Type: text/plain

Regarding section 3.5.5.1.2.2.  What if I just want EPC's (results from Gen2
Ack command).  Do I issue an Access command with no OpCode TLV?
 
Rob Buck
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C57900.D49539BC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D6.E2246E60">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle18
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DGramE><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial'>Regarding section 3.5.5.1.2.2.</span></font></span><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-spacerun:yes'>&nbsp; </span><span =
class=3DGramE>What</span> if I just
want <span class=3DSpellE>EPC's</span> (results from Gen2 <span =
class=3DSpellE>Ack</span>
command).<span style=3D'mso-spacerun:yes'>&nbsp; </span>Do I issue an =
Access
command with no <span class=3DSpellE>OpCode</span> =
TLV?<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob =
Buck</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C57900.D49539BC--


--===============2139753522==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============2139753522==--




From rfid-bounces@lists.ietf.org Fri Jun 24 17:09:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlvQe-00065X-OU; Fri, 24 Jun 2005 17:09:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvQd-00065J-1Z
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 17:09:35 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25299
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 17:09:31 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLTW>; Fri, 24 Jun 2005 16:09:17 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E0391@normail.norand.com>
To: rfid@ietf.org
Date: Fri, 24 Jun 2005 16:09:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] RE: draft-krishna-slrrp-02: Repeated Inventory Operations
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>
Content-Type: multipart/mixed; boundary="===============1222388550=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============1222388550==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57900.F5D7272A"

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_01C57900.F5D7272A
Content-Type: text/plain

If I issue an Inventory command, does it execute the previous access
commands?  If I then issue another inventory command does it re-execute the
same access commands?  If so, I don't see how you clear the list of access
commands.
 
I assume that 3.4.7 STOP_INVENTORY is used to terminate an inventory that's
operating for an extended period on possibly many tag operations defined by
multiple access commands?
 
Rob Buck
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C57900.F5D7272A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D7.036E7700">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle18
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle19
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>If I issue
an Inventory command, does it execute the previous access =
commands?<span
style=3D'mso-spacerun:yes'>&nbsp; </span>If I then issue another =
inventory
command does it re-execute the same access commands?<span
style=3D'mso-spacerun:yes'>&nbsp; </span>If so, I don't see how you =
clear the
list of access commands.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></f=
ont></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>I assume
that 3.4.7 STOP_INVENTORY is used to terminate an inventory that's =
operating
for an extended period on possibly many tag operations defined by =
multiple
access commands?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob =
Buck</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C57900.F5D7272A--


--===============1222388550==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1222388550==--




From rfid-bounces@lists.ietf.org Fri Jun 24 17:10:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DlvR8-0006Ef-Vz; Fri, 24 Jun 2005 17:10:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvR6-0006Ds-4L
	for rfid@megatron.ietf.org; Fri, 24 Jun 2005 17:10:04 -0400
Received: from agate.intermec.com (agate.intermec.com [63.127.92.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25333
	for <rfid@lists.ietf.org>; Fri, 24 Jun 2005 17:10:01 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BLTY>; Fri, 24 Jun 2005 16:09:47 -0500
Message-ID: <49E558014BABD711AA980002A5421C999E0392@normail.norand.com>
To: Rob.Buck@intermec.com, rfid@ietf.org
Date: Fri, 24 Jun 2005 16:09:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Cc: 
Subject: [Rfid] draft-krishna-slrrp-02: Filter vs Target Tag parms
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>
Content-Type: multipart/mixed; boundary="===============1553202369=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============1553202369==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57901.0BF335C6"

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_01C57901.0BF335C6
Content-Type: text/plain

Section 3.5.5.1.1.3 defines filter parms associated with the inventory
command in terms of the Gen2 select command.  This appears to conflict with
3.5.5.1.2.1 where target tag parms are associated with an access command.
 
Rob Buck
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C57901.0BF335C6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C578D7.198A8F60">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>125</w:Zoom>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle18
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle19
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle20
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	mso-text-animation:none;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none;
	text-underline:none;
	text-decoration:none;
	text-line-through:none;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Section 3.5.5.1.1.3
defines filter <span class=3DSpellE>parms</span> associated with the =
inventory
command in terms of the Gen2 select command.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>This appears to conflict with
3.5.5.1.2.1 where target tag <span class=3DSpellE>parms</span> are =
associated
with an access command.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;mso-no-proof:yes'>Rob =
Buck</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C57901.0BF335C6--


--===============1553202369==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1553202369==--




From rfid-bounces@lists.ietf.org Sun Jun 26 12:00:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmZYl-00021z-3N; Sun, 26 Jun 2005 12:00:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZYi-00021S-RY
	for rfid@megatron.ietf.org; Sun, 26 Jun 2005 12:00:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06862
	for <rfid@ietf.org>; Sun, 26 Jun 2005 12:00:33 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmXPz-0001tP-Pv
	for rfid@ietf.org; Sun, 26 Jun 2005 09:43:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C57A51.5D1DD543"
Subject: RE: [Rfid] RE: draft-krishna-slrrp-02: Are Access Commands Batched?
Date: Sun, 26 Jun 2005 09:17:12 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16EBFF2CF@ms08.mse3.exchange.ms>
X-MS-Has-Attach: yes
Thread-Topic: [Rfid] RE: draft-krishna-slrrp-02: Are Access Commands Batched?
Thread-Index: AcV4/8tVGYacRc2fQ4SYAe+FKDcbQwBT6MCy
From: "P. Krishna" <pkrishna@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8
Cc: 
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

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57A51.5D1DD543
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C57A51.5D1DD543"


------_=_NextPart_002_01C57A51.5D1DD543
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

________________________________

From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Fri 6/24/2005 5:00 PM
To: rfid@ietf.org
Subject: [Rfid] RE: draft-krishna-slrrp-02: Are Access Commands Batched?

Each Access command defines an operation such as Read, Write, Kill, etc. =
 Does the reader effectively batch these commands and execute them only =
after receiving an inventory command?  If so, what's the need for 3.4.11 =
STOP_ACCESS?  Executing an access command should be instantaneous.

=20

Rob Buck

=20

=20

Hi Rob,
=20
I had prepared the following writeup for another reader vendor for =
access-spec clarifications. I hope this will clarify what access command =
does versus an inventory command. In the text are also a list of =
usecases and the associated slrrp commands.
=20
I hope this helps.
=20
/Krishna



"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20


------_=_NextPart_002_01C57A51.5D1DD543
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<html                                                                    =
                                                                      >=0A=
=0A=
<head>=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
<style>=0A=
<!--=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{=0A=
	margin:0in;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman";}=0A=
a:link, span.MsoHyperlink=0A=
	{color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{color:purple;=0A=
	text-decoration:underline;}=0A=
span.EmailStyle17=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.GramE=0A=
	{}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</style>=0A=
=0A=
</head>=0A=
=0A=
<body vlink=3D"purple" link=3D"blue" lang=3D"EN-US" >=0A=
<DIV id=3DidOWAReplyText97961 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>=0A=
<DIV></FONT>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> rfid-bounces@lists.ietf.org on =
behalf of =0A=
Rob.Buck@intermec.com<BR><B>Sent:</B> Fri 6/24/2005 5:00 =
PM<BR><B>To:</B> =0A=
rfid@ietf.org<BR><B>Subject:</B> [Rfid] RE: draft-krishna-slrrp-02: Are =
Access =0A=
Commands Batched?<BR></FONT><BR><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Each Access command =
defines an =0A=
operation such as Read, Write, Kill, etc.<SPAN>&nbsp; </SPAN>Does the =
reader =0A=
effectively batch these commands and execute them only after receiving =
an =0A=
inventory command?<SPAN>&nbsp; </SPAN><SPAN class=3DGramE>If so, what's =
the need =0A=
for 3.4.11 STOP_ACCESS?</SPAN><SPAN>&nbsp; </SPAN>Executing an access =
command =0A=
should be instantaneous.</SPAN></FONT></DIV></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<DIV>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Rob =0A=
Buck</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">=0A=
<DIV id=3DidOWAReplyText97961 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>=0A=
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2>Hi =
Rob,</FONT></DIV>=0A=
<DIV>=0A=
<DIV id=3DidOWAReplyText97961 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>=0A=
<DIV></FONT>&nbsp;</DIV></DIV></DIV></DIV>=0A=
<DIV><FONT face=3DArial size=3D2>I had prepared the following writeup =
for another =0A=
reader vendor for access-spec clarifications. I hope this will clarify =
what =0A=
access command does versus an inventory command. In the text =0A=
are&nbsp;also&nbsp;a list of&nbsp;usecases and the associated slrrp =0A=
commands.</FONT></DIV><FONT face=3DArial size=3D2></FONT></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2><FONT =
face=3DArial size=3D2>=0A=
<DIV>&nbsp;</DIV>=0A=
<DIV>I hope this helps.</DIV>=0A=
<DIV>&nbsp;</DIV>=0A=
<DIV>/Krishna<BR></DIV></FONT></FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR></DIV></SPAN></FONT></DIV></DIV></DIV>=0A=
=0A=
</body>=0A=
=0A=
</html>=0A=
=0A=
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>=0A=

------_=_NextPart_002_01C57A51.5D1DD543--

------_=_NextPart_001_01C57A51.5D1DD543
Content-Type: text/plain;
	name="usecases.txt"
Content-Transfer-Encoding: base64
Content-Description: usecases.txt
Content-Disposition: attachment;
	filename="usecases.txt"
Content-Transfer-Encoding: base64

VVNFQ0FTRVMgQU5EIFNMUlJQIEFDQ0VTUy1TUEVDUwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09CgpBY2Nlc3MgY29tbWFuZCBjcmVhdGVzIGFuIGFjY2Vzcy1zcGVjIGF0IHRoZSByZWFk
ZXIuIFN0b3AgQWNjZXNzIGNvbW1hbmQKZGVsZXRlcyBhbiBhY2Nlc3Mtc3BlYyBpbiB0aGUgcmVh
ZGVyLgoKQWNjZXNzLXNwZWNzIGFyZSBhIHNldCBvZiA8dGFnLXNwZWMsIG9wLXNwZWM+IHR1cGxl
czoKKiB0YWctc3BlYyBkZWZpbmVzIHRoZSB0YWcgZmlsdGVyIG1hc2sKKiBvcC1zcGVjIGRlZmlu
ZXMgdGhlIG9wZXJhdGlvbnMgdG8gYmUgcGVyZm9ybWVkIGF0IHRoZSB0YWcuCgp3aGVyZSwgYWNj
ZXNzIG9wZXJhdGlvbiA9IGFsbCB0eXBlcyBvZiBvcGVyYXRpb25zOiByZWFkaW5nL3dyaXRpbmcK
dXNlciBtZW1vcnksIGxvY2ssIHVubG9jaywga2lsbCwgdGFnIGludmVudG9yeS4KCkFjY2Vzcy1z
cGVjcyBkbyBub3QgYnkgaXRzZWxmIHRyaWdnZXIgYW4gYWlyLXByb3RvY29sIGNvbW1hbmQgdG8g
YmUgc2VudC4gSW52ZW50b3J5CmNvbW1hbmRzIGFyZSByZXF1aXJlZCBmcm9tIHRoZSBob3N0IHRv
IGdldCB0aGUgcmVhZGVyIHRvIHNpbmd1bGF0ZSBhbmQgcmVhZCB0aGUgRVBDcyAKZnJvbSB0aGUg
dGFncy4gVGhlIHJlYWRlciBsb29rcyB1cCB0aGUgdGFncyBpbiB0aGUgYWNjZXNzLXNwZWMgbWVt
b3J5IHRvIHNlZSBpZiB0aGVyZSAKaXMgYW55IG1hdGNoLiBVcG9uIGEgbWF0Y2ggd2l0aCB0aGUg
dGFnLXNwZWMgaW4gYW4gYWNjZXNzLXNwZWMsIHRoZSBvcGVyYXRpb24ocykgYXMgCnNwZWNpZmll
ZCBpbiB0aGUgY29ycmVzcG9uZGluZyBvcC1zcGVjIGlzIHRha2VuLgoKVGhlIGludmVudG9yeSBj
b21tYW5kIGluIFNMUlJQIHNwZWNpZmllcyB0aGUgUkYsIHNpbmd1bGF0aW9uICdzZWxlY3QgZmls
dGVycycsIHRpbWUtb3BlcmF0aW9uIApwYXJhbWV0ZXJzLCBhbmQgdGhleSBhcmUgY2hvc2VuIHRv
IG9wdGltaXplIHRoZSBSRiBlbnZpcm9ubWVudCB3aXRob3V0IGNvbXByb21pc2luZyB0aGUgCidu
ZWNlc3NhcnknIHRhZy1yZWFkcy4KCkF0IGEgaGlnaCBsZXZlbCwgaW52ZW50b3J5IGNvbW1hbmQg
aXMgdXNlZCBmb3IgUkYgbWFuYWdlbWVudCwgdGFnLWFjcXVpc2l0aW9uOyBhY2Nlc3MgY29tbWFu
ZAppcyB1c2VkIGZvciBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMgb2YgdGFnLWFjY2Vzcy4KCgpJ
J2xsIHRyeSB0byBhbmNob3IgZWFjaCBvZiB0aGUgdXNlIGNhc2Ugd2l0aCBzb21lIHByYWN0aWNh
bCBzY2VuYXJpb3MuIEFzc3VtZSB0aGF0IHRoZQpmb2xsb3dpbmcgdXNlIGNhc2VzIGFyZSBmb3Ig
YSBkb2NrIGRvb3IgYXQgYSByZXRhaWxlcidzIERDIC0gaS5lLiwgYWxsIHRoZSBiZWxvdyBldmVu
dHMgCmNhbiBoYXBwZW4gYXQgdGhlIGRvY2sgZG9vciAtIHdoaWNoIG1lYW5zLCB0aGUgcmVhZGVy
IHNob3VsZCBoYXZlIHRoZXNlIGFjY2VzcyBjYXBhYmlsaXRpZXMgCnRoYXQgbmVlZHMgdG8gYmUg
ZXhlY3V0ZWQgZGF5IGluIGFuZCBkYXkgb3V0LiBJJ2xsIHJlZmVyIHRvIHRoYXQgcmVhZGVyIGFz
IHRoZSBSZXRhaWxERF9SZHIuCgpGb3IgZWFjaCB1c2UgY2FzZSwgSSdsbCBmaXJzdCBkZXNjcmli
ZSB0aGUgdXNlIGNhc2UsIGFuZCB0aGVuIGRlc2NyaWJlIHdoYXQgU0xSUlAgcHJvZ3JhbXMgaW50
byAKdGhlIFJldGFpbEREX1Jkci4KCgpVU0UgQ0FTRSAxOiBGb29kIHRyYWNlYWJpbGl0eSAoSEFD
Q1AgY29tcGxpYW5jZSkKV3JpdGluZyBhbmQgcmVhZGluZyBsb3QvYmF0Y2ggIyB0by9mcm9tIHRh
ZydzIHVzZXIgbWVtb3J5CgpUaGUgc3VwcGxpZXIgUzEgZHVyaW5nIHRhZyBjb21taXNzaW9uaW5n
IG9yIGxvdC9zdWItbG90IHNoaXBwaW5nIHRpbWUgYWxzbyB3cml0ZXMgdGhlIGxvdC9iYXRjaCAj
IGludG8gCnRoZSBwYWxsZXQgdGFnJ3MgdXNlciBtZW1vcnkuIFBhbGxldCB0YWdzIHNoYXJlIGEg
cHJlZml4ICJwcmVmaXgtUzEiLiBUaGUgbG90L2JhdGNoICMgaXMgMzIgYml0cyB3aWRlLgoKVGhl
IHJlYWRlciBhdCB0aGUgcmV0YWlsZXIgREMgZG9jayBkb29yIHJlYWRzIHRoZSBwYWxsZXQgdGFn
OyBCYXNlZCBvbiB0aGUgcGFsbGV0IHRhZywgdGhlIHJlYWRlcgp0aGVuIGRlY2lkZXMgdG8gcmVh
ZCB0aGUgdXNlciBtZW1vcnkgYW5kIGdldHMgdGhlIGxvdC9iYXRjaCAjLiBUaGUgcmVhZGVyIHBh
c3NlcyB0aGUgPHRhZywgbG90Iz4gdG8gdGhlCmFwcGxpY2F0aW9uLgoKU0xSUlAgYWN0aW9uOgpG
b2xsb3dpbmcgaXMgdGhlIGFjY2VzcyBzcGVjIHByb2dyYW1tZWQgQCB0aGUgUmV0YWlsRERfUmRy
IC4uLgoKYWNjZXNzLXNwZWMxOiAKdGFnLXNwZWM6IE1hdGNoZXMgdHlwZT1wYWxsZXQsIFRhZyBw
cmVmaXggPSAicHJlZml4LVMxIgpvcC1zcGVjOiBSZWFkIDMyIGJpdHMgZnJvbSB1c2VyIG1lbW9y
eQoKClVTRSBDQVNFIDI6IENvbGQgQ2hhaW4gU3lzdGVtcyAoSEFDQ1AgY29tcGxpYW5jZSkKRGV0
ZWN0IGlmIHRlbXBlcmF0dXJlIGF0IHdoaWNoIHRoZSBwcm9kdWN0IGhhcyBiZWVuIHN0b3JlZCBo
YXMgbW92ZWQgb3V0c2lkZSB0aGUgcXVhbGl0eSB0b2xlcmFuY2UgbGV2ZWxzClRoZXJlIGFyZSBj
b3VwbGUgKG9yIG1vcmUpIHdheXMgdG8gZG8gdGhpczogKGkpIHRhZyBpdHNlbGYgaXMgYSB0ZW1w
ZXJhdHVyZSBsb2dnZXIgYW5kIHBlcmlvZGljYWxseSBtZWFzdXJlcyB0aGUKdGVtcGVyYXR1cmUg
YW5kIHdyaXRlcyBpdCBpbiB0aGUgdXNlciBtZW1vcnkgLSBlLmcuLCBDeVRoZXJtIHRhZ3MuIChp
aSkgQXQgZWFjaCByZWFkIHBvaW50IGFsb25nIHRoZSBzdXBwbHkgY2hhaW4sCnRoZSByZWFkZXJz
IHJlYWQgdGhlIHRlbXBlcmF0dXJlIHNlbnNvcnMgYW5kIHdyaXRlIGFuIGFsYXJtIGludG8gdGhl
IHVzZXIgbWVtb3J5IG9mIHRoZSB0YWcgaWYgdGhlcmUgaXMgYSB2aW9sYXRpb24uCkFzIHBhcnQg
b2YgdGhlIHdyaXRlID0ge2xvY2F0aW9uIG9mIGZhdWx0fQoKSW4gZWl0aGVyIGNhc2UsIHRoZSBy
ZWFkZXIgYXQgdGhlIHJldGFpbGVyIERDIHJlYWRzIHRoZSB0YWcncyB1c2VyIG1lbW9yeSB0byBj
aGVjayBpZiB0aGVyZSBhcmUgYW55IGFsYXJtcyAtIGlmCnRoZXJlIGlzIGluZGVlZCBhbiBhbGFy
bSBldmVudCB0aGUgcmVhZGVyIHBhc3NlcyB0aGF0IGluZm9ybWF0aW9uIHRvIHRoZSBwdXRhd2F5
IGFwcGxpY2F0aW9uIHdoaWNoIGluc3RydWN0cyB0aGUKb3BlcmF0b3IgdG8gc2VuZCB0aGUgcGFs
bGV0IHRvIHJldHVybnMvcmVqZWN0IGFyZWEgaW5zdGVhZCBvZiBhIHB1dGF3YXkgbG9jYXRpb24g
aW4gdGhlIERDLgoKTGV0cyBhc3N1bWUgdGhhdCBwYWxsZXRzIGZyb20gdGhpcyBzdXBwbGllciBT
MiBzaGFyZSBhIHByZWZpeCAicHJlZml4LVMyIi4gQW5kIGFzc3VtZSB0aGF0IHRoZSBpbmZvcm1h
dGlvbiB0byBiZSAKcmVhZCBmcm9tIHRoZSB1c2VyIG1lbW9yeSBpcyAxNiBiaXRzLgoKU0xSUlAg
YWN0aW9uOgphY2Nlc3Mtc3BlYzI6CnRhZy1zcGVjOiBNYXRjaGVzIHR5cGU9cGFsbGV0LCBUYWcg
cHJlZml4ID0gInByZWZpeC1TMiIKb3Atc3BlYzogUmVhZCAxNiBiaXRzIGZyb20gdXNlciBtZW1v
cnkuCgoKVVNFIENBU0UgMzogRXhwaXJ5IGRhdGUgaW4gdXNlciBmaWVsZCAocGhhcm1hKQpTYW1l
IGFzIGluIFVzZSBDYXNlIDEsIGluc3RlYWQgb2YgbG90L2JhdGNoIywgdGhlIHN1cHBsaWVyIHdy
aXRlcyB0aGUgZXhwaXJ5IGRhdGUgaW50byB0aGUgdXNlcgptZW1vcnkuIFRoZSByZWFkZXIgYXQg
dGhlIHJldGFpbGVyIERDIGRvY2sgZG9vciByZWFkcyB0aGUgZXhwaXJ5IGRhdGUgZnJvbSB0aGUg
dXNlciBtZW1vcnkgYW5kIApwYXNzZXMgaXQgdG8gdGhlIHJlY2VpdmluZyBhcHBsaWNhdGlvbi4g
VGhlIHJlY2VpdmluZyBhcHBsaWNhdGlvbiBtYXkgZGVjaWRlIHRvICJyZWplY3QvcmV0dXJuIiB0
aGUKZHJ1ZyBwYWxsZXQvY2FzZSwgb3IgZGVjaWRlIHRvIHBlcmZvcm0gYW4gaW50ZWxsaWdlbnQg
cHV0YXdheSBiYXNlZCBvbiBleHBpcnkgZGF0ZS4KCkxldCB1cyBzYXkgdGhlIHN1cHBsaWVyIGlz
IFMzIGFuZCB0aGUgcGFsbGV0IHRhZ3Mgc2hhcmUgYSBwcmVmaXggInByZWZpeC1TMyIuCgpTTFJS
UCBhY3Rpb246CmFjY2Vzcy1zcGVjMzoKdGFnLXNwZWM6IE1hdGNoZXMgdHlwZT1wYWxsZXQsIFRh
ZyBwcmVmaXggPSAicHJlZml4LVMzIgpvcC1zcGVjOiBSZWFkIDMyIGJpdHMgZnJvbSB1c2VyIG1l
bW9yeS4KClVTRSBDQVNFIDQ6IFRJRCBiYXNlZCBhY2Nlc3MgcnVsZXMKU3VwcG9zZSwgYW4gYXBw
bGljYXRpb24gcmVxdWlyZXMgdGhlIGZvbGxvd2luZyBidXNpbmVzcyBsb2dpYzoKLSBEb2NrLWRv
b3IgcmVhZGVyIHRvIHdyaXRlIGluZm9ybWF0aW9uIGluIHRoZSB1c2VyLW1lbW9yeSBvZiBwYWxs
ZXQgdGFncyBmcm9tIG1hbnVmYWN0dXJlciBTNC4KCkFzIHlvdSBrbm93LCB0aGUgdXNlci1tZW1v
cnkgYW5kIGJsb2NrIHdyaXRlIGNhcGFiaWxpdGllcyBhcmUgb3B0aW9uYWwgCmZvciBDMSB0YWdz
IGluIEcyLiBMZXRzIHNheSwgdGhpcyBkb2NrLWRvb3Igc2VlcyB0YWdzIGZyb20gbWFudWZhY3R1
cmVycwpmb28xLCBmb28yIGFuZCBvdGhlcnMgLSB0aGVzZSBhcmUgdGFnIG1hbnVmYWN0dXJlcnMg
bGlrZSBJbXBpbmogZXRjIGFuZCBfbm90XyB0aGUgc3VwcGxpZXJzIGxpa2UgUCZHIGV0Yy4gCkFu
ZCBsZXRzIHN1cHBvc2UsIHRoZSBUSUQgdGFibGUgbG9va3MgYXMgZm9sbG93czogICAKClRJRCAg
ICBVc2VyIE1lbW9yeSAgIEJsb2NrV3JpdGVDYXBhYmlsaXR5CmZvbzEgICAgICBZZXMgICAgICAg
ICAgICAgIFllcyAgCmZvbzIgICAgICBObyAgICAgICAgICAgICAgICBObyAgICAKKiAgICAgICAg
IFllcyAgICAgICAgICAgICAgIE5vICAgIC8vIFRoaXMgZW50cnkgaXMgZm9yIHRoZSByZXN0IG9m
IFRJRHMuCgpTTFJSUCBhY3Rpb24gLSBDcmVhdGUgMyBhY2Nlc3Mtc3BlY3MgYXQgdGhlIHJlYWRl
cjoKCmFjY2Vzcy1zcGVjNDogCnRhZy1zcGVjOiBNYXRjaGVzIFRJRD1mb28xIGFuZCB0eXBlPXBh
bGxldCBhbmQgVGFnIHByZWZpeCA9ICJwcmVmaXgtUzQiCm9wLXNwZWM6IEJsb2NrIFdyaXRlIHRp
bWUgYW5kIGRvY2sgZG9vciAjIHRvIHVzZXIgbWVtb3J5CgphY2Nlc3Mtc3BlYzU6dGFnLXNwZWM6
IE1hdGNoZXMgVElEPWZvbzIgYW5kIHR5cGU9cGFsbGV0IGFuZCBUYWcgcHJlZml4ID0gInByZWZp
eC1TNCIKb3Atc3BlYzogbm8gb3AuCgphY2Nlc3Mtc3BlYzY6dGFnLXNwZWM6IE1hdGNoZXMgVElE
PSogYW5kIHR5cGU9cGFsbGV0IGFuZCBUYWcgcHJlZml4ID0gInByZWZpeC1TNCIKb3Atc3BlYzog
V3JpdGUgdGltZSBhbmQgZG9jayBkb29yICMgdG8gdXNlciBtZW1vcnkKClVTRSBDQVNFIDU6IER5
bmFtaWMgaW52ZW50b3J5ClRoaXMgdXNlIGNhc2UgaXMgbm90IHJlbGF0ZWQgdG8gYWNjZXNzLCBi
dXQgbW9yZSBmb3IgdHJpZ2dlcmluZyBjYXNlIGxldmVsIGludmVudG9yeS4gU3VwcG9zZQp0aGUg
ZG9jayBkb29yIHJlYWRlciBSZXRhaWxERF9SZHIgaXMgYnkgZGVmYXVsdCBvbmx5IG1vbml0b3Jp
bmcgb3IgbG9va2luZyBmb3IgcGFsbGV0IHRhZ3MgCih1c2luZyBHMiBzZWxlY3QgY29tbWFuZCku
IEhvd2V2ZXIsIHdoZW4gdGhlIGRvY2sgZG9vciByZWFkZXIgc2VlcyBhIHBhbGxldCBvZiBjZXJ0
YWluIHR5cGUsIHRoZSAKYnVzaW5lc3MgbG9naWMgaXMgdG8gY2FwdHVyZSB0aGUgcGFsbGV0IGNv
bnRlbnRzLgoKRm9yIHRoaXMgZXhhbXBsZSwgbGV0cyBzYXkgd2hlbmV2ZXIgd2Ugc2VlIHBhbGxl
dHMgaGF2aW5nIGEgcHJlZml4ID0gInByZWZpeC1TNSIsIHdlIGFyZSBpbnRlcmVzdGVkIGluCnJl
YWRpbmcgdGhlIGNhc2UgdGFncyB0b28uCgpTTFJSUCBhY3Rpb246CmFjY2Vzcy1zcGVjNzoKdGFn
LXNwZWM6IE1hdGNoZXMgdHlwZT1wYWxsZXQgYW5kIFRhZyBwcmVmaXggPSAicHJlZml4LVM1Igpv
cC1zcGVjOiBTZW5kIHNlbGVjdCA9IDxjYXNlIHRhZyB0eXBlPgogICAgICAgICBpbnZlbnRvcnkg
dGFncyBmb3IgZGVsdGEgdGltZQogICAgICAgICBnbyBiYWNrIHRvIGRlZmF1bHRzCgoKU28sIGJh
c2VkIG9uIHRoZSBidXNpbmVzcyBsb2dpYyByZXF1aXJlbWVudHMgZnJvbSB0aGUgNSB1c2UgY2Fz
ZXMsIHRoaXMgZG9jayBkb29yIHJlYWRlciBSZXRhaWxERF9SZHIgCmhhcyA3IGFjY2Vzcy1zcGVj
cyBwcm9ncmFtbWVkIHVzaW5nIFNMUlJQLiBUaGVzZSBhY2Nlc3Mtc3BlY3MgYXJlIGxvb2tlZCBh
dCBkdXJpbmcgZXZlcnkgaW52ZW50b3J5IG9wZXJhdGlvbi4K

------_=_NextPart_001_01C57A51.5D1DD543
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

------_=_NextPart_001_01C57A51.5D1DD543--




From rfid-bounces@lists.ietf.org Sun Jun 26 12:01:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmZZ7-000298-II; Sun, 26 Jun 2005 12:01:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZZ3-00027q-W4
	for rfid@megatron.ietf.org; Sun, 26 Jun 2005 12:00:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07113
	for <rfid@ietf.org>; Sun, 26 Jun 2005 12:00:54 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmX8E-000061-61
	for rfid@ietf.org; Sun, 26 Jun 2005 09:25:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] draft-krishna-slrrp-02: Data "smoothing"
Date: Sun, 26 Jun 2005 08:58:46 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16EBFF2CD@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] draft-krishna-slrrp-02: Data "smoothing"
Thread-Index: AcV4+3DNRZei0vJfRy+ARJ7Lp7TgTgBTq8V2
From: "P. Krishna" <pkrishna@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: e5bfa71b340354e384155def5e70b13b
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0381799068=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0381799068==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57A4E.CA0E0B01"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57A4E.CA0E0B01
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Rob,
We stayed away from defining an elaborate smoothing engine in SLRRP. =
Basically, there are 2 knobs we provide to control the traffic rate from =
the reader:
(i) the frequency (rate) of the inventory and access reports generated =
and transmitted by the reader to the RNC - this is controlled by =
defining 'triggers' in Section 3.5.6.1. The trigger is a byte wide - =
different types of triggers can be defined. We have currently defined =
only 2 types - one of them says send the report every inventory round, =
the other says send the report every T time units. We are open to =
defining more types of triggers.=20
=20
(ii) the frequency of the tag data itself inside the report: this seems =
to be the major concern of a RFID reader network.  Just so everybody is =
on the same page, I'll just illustrate with a simple example. A reader =
can see a tag many times (say 10 times) during an inventory round - a =
simple implementation is to have the report the tag 10 times in the =
report - i.e., if the tag data is 100B, then we are consuming 10 * 100B =
=3D 1 KB on the wire. If this happens to each and every tag seen by the =
reader, then we are consuming 10x of the bandwidth and there is "no" =
perceived extra information conveyed in the duplicate data.
=20
There is a class of applications or hosts that is just interested in =
knowing a binary information per tag by the reader (i.e., has the reader =
seen it or not) - for them, sending 10 instances of each tag is a waste =
and redundant. Instead they would like a clean list of N tags 'observed' =
by the reader.
As you are aware that there is already a application-layer protocol =
(ALE) in EPCglobal that provides that interface - unfortunately I cannot =
go into those details in this mailing list. ALE provides the right =
reader interface to those applications.
=20
We dont believe in wasting bandwidth on the network (its obvious from =
one of our design points - binary encoding). But, we also believe that =
there is 'rich' information in knowing how many times a tag was observed =
by the reader - this provides information of the quality of the read. An =
infrastructure device can do some richer inference from such information =
from multiplicity of readers.=20
=20
We have a 'RFU' (reserved for future use) field in the "Tag Data =
Parameter" (section 3.5.6.3) - we intend to use that field to send =
information like the "number of times the tag was seen", "the RF =
frequency at which it was captured" etc. So, if a tag is seen 10 times, =
we set the "number of times the tag was seen" for that tag to 10. This =
way, we are not sending 10x traffic, but still are able to convey the =
rich information up to the infrastructure device.
=20
I hope that helps.
=20
/Krishna
=20
=20
=20

________________________________

From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Fri 6/24/2005 4:28 PM
To: rfid@ietf.org
Subject: [Rfid] draft-krishna-slrrp-02: Data "smoothing"



Does SLRRP provide a mechanism for "smoothing" RFID data - i.e., =
eliminating duplicate reads?  If not, is there no concern about =
unnecessary network traffic transmitting a significant amount of =
redundant data?

=20

Rob

=20

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20


------_=_NextPart_001_01C57A4E.CA0E0B01
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<html                                                                    =
                                                                      >=0A=
=0A=
<head>=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
<style>=0A=
<!--=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{=0A=
	margin:0in;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman";}=0A=
a:link, span.MsoHyperlink=0A=
	{color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{color:purple;=0A=
	text-decoration:underline;}=0A=
span.EmailStyle17=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</style>=0A=
=0A=
</head>=0A=
=0A=
<body vlink=3D"purple" link=3D"blue" lang=3D"EN-US" >=0A=
<DIV id=3DidOWAReplyText73018 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Rob,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>We stayed away from defining =
an elaborate =0A=
smoothing engine in SLRRP. Basically, there are 2 knobs we provide to =
control =0A=
the traffic rate from the reader:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>(i) the frequency =
(rate)&nbsp;of the =0A=
inventory and access reports generated and transmitted by the reader to =
the RNC =0A=
- this is controlled by defining 'triggers' in Section 3.5.6.1. The =
trigger is a =0A=
byte wide - different types of triggers can be defined. We have =
currently =0A=
defined only 2 types - one of them says send the report every inventory =
round, =0A=
the other says send the report every T time units. We are open to =
defining more =0A=
types of triggers. </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>(ii) the frequency of the tag =
data itself =0A=
inside the report: this&nbsp;seems to be&nbsp;the major concern of a =
RFID reader =0A=
network.&nbsp; Just so everybody is on the same page, I'll just =
illustrate with =0A=
a simple example. A reader can see a tag many times (say 10 times) =
during an =0A=
inventory&nbsp;round - a simple implementation is to have the report the =
tag 10 =0A=
times in the report - i.e., if the tag data is 100B, then we are =
consuming 10 * =0A=
100B =3D 1 KB on the wire. If this happens to each and every tag seen by =
the =0A=
reader, then we are consuming 10x of the bandwidth and there is "no" =
perceived =0A=
extra information conveyed in the duplicate data.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>There is a class =
of&nbsp;applications =0A=
or&nbsp;hosts that&nbsp;is just interested in knowing a binary =
information per =0A=
tag&nbsp;by the reader (i.e., has the reader seen it or not) - for them, =
sending =0A=
10 instances of each tag is a waste and redundant. Instead they would =
like a =0A=
clean list of N tags 'observed' by the reader.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>As you are aware that there =
is already a =0A=
application-layer protocol (ALE) in EPCglobal that&nbsp;provides that =
interface =0A=
- unfortunately I cannot go into those details in this mailing =
list.&nbsp;ALE =0A=
provides the right reader interface to those applications.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>We dont believe in wasting =
bandwidth on the =0A=
network (its obvious from one of our design points&nbsp;- binary =
encoding). But, =0A=
we also believe that there is 'rich' information in knowing how many =
times a tag =0A=
was observed by the reader - this provides information of the quality of =
the =0A=
read. An infrastructure device can do some richer inference from such =0A=
information from multiplicity of readers. </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>We have a 'RFU' (reserved for =
future use) =0A=
field in the "Tag Data Parameter" (section 3.5.6.3) - we intend to use =
that =0A=
field to send information like the "number of times the tag was seen", =
"the RF =0A=
frequency at which it was captured" etc. So, if a tag is seen 10 times, =0A=
we&nbsp;set the "number of times the tag was seen" for that tag to 10. =
This way, =0A=
we are not sending 10x traffic, but still are able to convey the rich =0A=
information up to the infrastructure device.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I hope that =
helps.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>/Krishna</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> rfid-bounces@lists.ietf.org on =
behalf of =0A=
Rob.Buck@intermec.com<BR><B>Sent:</B> Fri 6/24/2005 4:28 =
PM<BR><B>To:</B> =0A=
rfid@ietf.org<BR><B>Subject:</B> [Rfid] draft-krishna-slrrp-02: Data =0A=
"smoothing"<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Does SLRRP =
provide a =0A=
mechanism for "smoothing" RFID data - i.e., eliminating duplicate reads? =0A=
<SPAN>&nbsp;</SPAN>If not, is there no concern about unnecessary network =
traffic =0A=
transmitting a significant amount of redundant data?</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Rob</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =0A=
style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV></DIV>=0A=
=0A=
</body>=0A=
=0A=
</html>=0A=
=0A=
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>=0A=

------_=_NextPart_001_01C57A4E.CA0E0B01--


--===============0381799068==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0381799068==--




From rfid-bounces@lists.ietf.org Sun Jun 26 18:38:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dmflp-0006CC-Sd; Sun, 26 Jun 2005 18:38:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dma66-0006bf-0l
	for rfid@megatron.ietf.org; Sun, 26 Jun 2005 12:35:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06224
	for <rfid@ietf.org>; Sun, 26 Jun 2005 11:59:44 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmY1h-0000IX-Pb
	for rfid@ietf.org; Sun, 26 Jun 2005 10:22:26 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C57A56.D104D1E2"
Subject: RE: [Rfid] draft-krishna-slrrp-02: Access Command to Inventory
	EPC'sonly
Date: Sun, 26 Jun 2005 09:51:29 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16EBFF2D2@ms08.mse3.exchange.ms>
X-MS-Has-Attach: yes
Thread-Topic: [Rfid] draft-krishna-slrrp-02: Access Command to Inventory
	EPC'sonly
Thread-Index: AcV5AQMk0mmlAB2lRdC0vfPa34K94gBVSRwI
From: "P. Krishna" <pkrishna@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 52005c17383d4e3f609075a067e11971
X-Mailman-Approved-At: Sun, 26 Jun 2005 18:38:32 -0400
Cc: 
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

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57A56.D104D1E2
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C57A56.D104D1E2"


------_=_NextPart_002_01C57A56.D104D1E2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Rob,
If you are just performing tag inventory - i.e., just get the EPCs of =
the tags in the field of view, then we dont have issue any Access =
command.
Here is a power point file that illustrates the SLRRP commands that =
achieve the following objective:
=20
- perform inventory of C1G2 tags with particular setting of singulation =
parameters, and RF parameters.
- get the tag report every inventory round.
=20
I hope this helps.
=20
/Krishna

________________________________

From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Fri 6/24/2005 5:08 PM
To: rfid@ietf.org
Subject: [Rfid] draft-krishna-slrrp-02: Access Command to Inventory =
EPC'sonly



Regarding section 3.5.5.1.2.2.  What if I just want EPC's (results from =
Gen2 Ack command).  Do I issue an Access command with no OpCode TLV?

=20

Rob Buck

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20


------_=_NextPart_002_01C57A56.D104D1E2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<html                                                                    =
                                                                      >=0A=
=0A=
<head>=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
<style>=0A=
<!--=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{=0A=
	margin:0in;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman";}=0A=
a:link, span.MsoHyperlink=0A=
	{color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{color:purple;=0A=
	text-decoration:underline;}=0A=
span.EmailStyle17=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle19=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.SpellE=0A=
	{}=0A=
span.GramE=0A=
	{}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</style>=0A=
=0A=
</head>=0A=
=0A=
<body vlink=3D"purple" link=3D"blue" lang=3D"EN-US" >=0A=
<DIV id=3DidOWAReplyText57542 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Hi =
Rob,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>If you are just performing =
tag inventory - =0A=
i.e., just get the EPCs of the tags in the field of view, then we dont =
have =0A=
issue any Access command.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Here is a power point file =
that illustrates =0A=
the SLRRP commands that achieve the following objective:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>- perform inventory =
of&nbsp;C1G2 tags with =0A=
particular setting of singulation parameters, and RF =
parameters.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>- get the tag report every =
inventory =0A=
round.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I hope this =
helps.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>/Krishna</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> rfid-bounces@lists.ietf.org on =
behalf of =0A=
Rob.Buck@intermec.com<BR><B>Sent:</B> Fri 6/24/2005 5:08 =
PM<BR><B>To:</B> =0A=
rfid@ietf.org<BR><B>Subject:</B> [Rfid] draft-krishna-slrrp-02: Access =
Command =0A=
to Inventory EPC'sonly<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><SPAN class=3DGramE><FONT face=3DArial =
size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Regarding section =0A=
3.5.5.1.2.2.</SPAN></FONT></SPAN><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN>&nbsp; </SPAN><SPAN =0A=
class=3DGramE>What</SPAN> if I just want <SPAN =
class=3DSpellE>EPC's</SPAN> (results =0A=
from Gen2 <SPAN class=3DSpellE>Ack</SPAN> command).<SPAN>&nbsp; =
</SPAN>Do I issue =0A=
an Access command with no <SPAN class=3DSpellE>OpCode</SPAN> =0A=
TLV?</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>=0A=
<DIV>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Rob =0A=
Buck</SPAN></FONT></P></DIV></DIV></DIV>=0A=
=0A=
</body>=0A=
=0A=
</html>=0A=
=0A=
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>=0A=

------_=_NextPart_002_01C57A56.D104D1E2--

------_=_NextPart_001_01C57A56.D104D1E2
Content-Type: application/vnd.ms-powerpoint;
	name="SLRRPExample.ppt"
Content-Transfer-Encoding: base64
Content-Description: SLRRPExample.ppt
Content-Disposition: attachment;
	filename="SLRRPExample.ppt"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAATgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////UwAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA
AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA
LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6
AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA
AABJAAAASgAAAEsAAABMAAAATQAAAP7////+////UAAAAFEAAABSAAAA/v////7/////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////1IA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAPDuq7RWesUB
TwAAAMAGAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAAAACZcAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0
AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEAwAAAAAAAAUARABvAGMAdQBtAGUAbgB0
AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAAAFgCAAAAAAAADwDo
A8EIAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID
FAEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEAcgBpAGEAbAAAAAgAAAAA
AAAAfLkTAHy5EwBoLKQA/LcTAOS3EwAW5wcwCAAAAAAAAAD8txMAelsJMPS3EwAAAAQAAACkDwgA
AACAAEAAAAD//wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAF
AP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8SAAAA
AAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSo
AAAADwAA8KAAAAAAAAbwSAAAAKIcAAAIAAAA/AAAAAcAAAABAAAABwAAAAIAAAAEAAAAAwAAAAQA
AAAEAAAAHgAAAAUAAAA6AAAABgAAAGwAAAAHAAAAogAAAIMAC/AwAAAAgQEEAAAIgwEAAAAIhkEA
AAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAD/////AQAACAIAAAj3AAAQ
HwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQB7sBAAAfABQEHAAAAAAAFQQU
AAAAWf+XFADKmjt7S4EzAMqaOwACAAMPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABKAAAAZAAA
AEoAAABkAAAACAAAAAAAAAAUuBMAelsJMAAAAAAAAAAAlPz//5r///8BABMAcAD7AwgAAAAAAAAA
cAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAEC4EwDf
HQkwfLkTAEAspAAAAAAAAAAAAAAAAAAAAAAAAAETAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEA
AABkAAAAQLgTAN8dCTB8uRMAQCykAAAAAAAAAAAAAAAAAAAAAAAAARMAHwD/AxQAAAACAAAEDAAA
AAAAAAAAAAAAAgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAAgAAAEC4EwC+PAkw
fLkTAAAAAAAAAAAAAAAAAAAAAAAAABMADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQ
AFQAMQAwAAAAixMQAAAAAAANBAgAAAAAwAAAAMAAAA8A8A/OBAAAAADzAxQAAAADAAAAAAAAAAIA
AAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8cAAAAU0xSUlAgQzFHMiBJbnZlbnRvcnkgRXhhbXBs
ZRAAnw8EAAAABQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAA
AAAAAJ8PBAAAAAAAAAAAAKgPCQAAAFVzZUNhc2UgMQAAqg8SAAAABwAAAAEAAAADAAMAAAAAAAAA
EACfDwQAAAABAAAAAACoD38AAABSZWFkIEMxRzIgdGFncyB3aXRoIFEgPSAxMCwgYXQgQW50ZW5u
YSAxIHdpdGggVFggcG93ZXIgPSBGVUxMLCBTZXNzaW9uICMgPSAzLg1TZW5kIHRhZyBsaXN0IHJl
cG9ydCB1cG9uIGVuZCBvZiBpbnZlbnRvcnkgcm91bmQuAADzAxQAAAAFAAAABAAAAAIAAAACAQAA
AAAAAAAAnw8EAAAAAAAAAAAAqA8IAAAAVGltZWxpbmUAAKEPFAAAAAkAAAAAAAAAAAAJAAAAAAAC
ACgAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAAGAAAABAAAAAIAAAADAQAA
AAAAAAAAnw8EAAAAAAAAAAAAqA8RAAAAU2V0X1JlYWRlcl9Db25maWcAAKoPEgAAABEAAAABAAAA
AwABAAAAAAAAABAAnw8EAAAAAQAAAAAAqA9ZAAAASXQgY2FycmllcyAyIHBhcmFtZXRlcnMNUkYg
dHJhbnNtaXR0ZXIgUGFyYW1ldGVyDUludmVudG9yeSBhbmQgQWNjZXNzIFJlcG9ydGluZyBQYXJh
bWV0ZXIAAKEPKgAAABgAAAAAAAAAAABCAAAAAQAAAAAAGAAAAAAAAgAUAEIAAAAABAIAAAQUAAAA
8wMUAAAABwAAAAYAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEQAAAEludmVudG9yeSBD
b21tYW5kAAChDxQAAAASAAAAAAAAAAAAEgAAAAAAAgAoABAAnw8EAAAAAQAAAAAAqA9bAAAASXQg
Y2FycmllcyAyIHBhcmFtZXRlcnMNSW52ZW50b3J5IE9wZXJhdGlvbiBUaW1pbmcgUGFyYW1ldGVy
DUVQQyBDMUcyIFNpbmd1bGF0aW9uIFBhcmFtZXRlcgAAoQ8uAAAAGAAAAAAAABAAAFoARAAAAAEA
ABAAAFoAGAAAAAAAAgAUAEQAAAAABAIAAAQSAAAAqg8aAAAARgAAAAAAAAALAAAAAQAAAAMACwAA
AAAAAAAAAPMDFAAAAAgAAAAGAAAAAgAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABJbnZl
bnRvcnkgYW5kIEFjY2VzcyBSZXBvcnQAAKEPFAAAABwAAAAAAAAAAAAcAAAAAAACACgAEACfDwQA
AAABAAAAAACoDz0AAABJdCBjYXJyaWVzIGEgbGlzdCBvZiB0YWcgcGFyYW1ldGVycw1UYWcgZGF0
YSBQYXJhbWV0ZXIgKDB4QTQpAAChDy4AAAAkAAAAAAAAEAAAWgAaAAAAAQAAEAAAWgAkAAAAAAAC
ABQAGgAAAAAEAgAABBIAAADqAwAAAAAPAPgDpAkAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAA
AAAAABMAYADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAGAA8AcgAAAA////
AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAAAP///wAAAAAAgICAAAAAAACZzP8A
zMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA////AI3G/wAAZswAAKgAAGAA8Acg
AAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABgAPAHIAAAAACAgAD///8AAFpYAP//
mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA////AFwfAADf0pMAzDMAAL55YAD//5kA06IZ
AGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/AP/nAQBgAPAHIAAAAAAAAAD///8A
M2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABoa10A////AHd3dwDR0csAkJCCAICeqAD/
zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZewBmZv8Amcz/AP//mQBgAPAHIAAAAFI+
JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAP8B
AGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8sAAAAAAMAABAAow98AAAABQD//T8A
AQAiIAAAZAAAAAD/AABkABQAAADYAAAAQAIAAAAABwAAAP//7wAAAAAA////////IAAAAAABAACA
BQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIAFACABQAAuwAQBYAE
AAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAB4AAAAAAAAAQAIAAAAABwAAAP//7wAA
AAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAA
gASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJAAAA
AAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAA
AAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAAAAIAFAADAAAAAAAA
AAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAAAAACABQAAgAAAAAA
AAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBNYEAAAPAALwzgQAABAACPAIAAAABgAA
AAYEAAAPAAPwZgQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAA
BQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAAfwABAAUAgADobaQAhwABAAAAgQEE
AAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAA
AADDCwgAAAAAAAAAAQCkAA8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0
IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8BYB
AAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEABQCAAIBwpACBAQQAAAiDAQAAAAi/AQEAEQDA
AQEAAAj/AQEACQABAgIAAAgAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAACAKQA
DwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5
bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIP
HgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPC2
AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAsd6QAgQEEAAAIgwEAAAAIvwEBABEA
wAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyABYAaKEA8AEfAQAAAAAADDCwgAAAACAAAABwGk
AA8ADfA+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIA
DgAAAPgPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABQQAAAAKAACDAAvwMAAAAH8AAQAFAIAA8Huk
AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg+wB9AOihAPABHw
EAAAAAAAwwsIAAAAAwAAAAkCpAAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAA
AAIAAAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABgQAAAAK
AACDAAvwMAAAAH8AAQAFAIAAuICkAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAA
CAAAEPAIAAAAXg8gEGAVihAPABHwEAAAAAAAwwsIAAAABAAAAAgCpAAPAA3wQAAAAAAAnw8EAAAA
BAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAAAAAAAAAP
AATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B
EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ
AJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsu
CAAAAOY+xQEghJG1IAC6DxwAAABEAGUAZgBhAHUAbAB0ACAARABlAHMAaQBnAG4ADwDuA6oBAAAC
AO8DGAAAAAAAAAAPEAAAAAAAAAAAAIAAAAAABwATAA8ADAQaAQAADwAC8BIBAAAgAAjwCAAAAAIA
AAADCAAADwAD8KoAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgA
AAUAAAAPAATwcgAAABIACvAIAAAAAggAACACAABTAAvwHgAAAH8AAAAEAIAAuNSkAL8BAAABAP8B
AAABAAEDAgQAAAAAEPAIAAAA0AWwAdAUbgkPABHwEAAAAAAAwwsIAAAAAAAAAA8ApAAPAA3wDAAA
AAAAng8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI
kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAA
AAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEA
MAAAAIsTEAAAAAAA6y4IAAAA5j7FASD1k7UPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAA
gAAAAAAHABMADwAMBJQBAAAPAALwjAEAADAACPAIAAAAAwAAAAMMAAAPAAPwJAEAAA8ABPAoAAAA
AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAADAAABQAAAA8ABPByAAAAEgAK8AgAAAAC
DAAAIAIAAFMAC/AeAAAAfwAAAAQAgABY+aQAvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACAB
YBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQCkAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAAS
AArwCAAAAAMMAAAgAgAAUwAL8B4AAAB/AAAABACAAPz5pAC/AQAAAQD/AQAAAQABAwMEAAAAABDw
CAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAKQADwAN8AwAAAAAAJ4PBAAAAAEAAAAP
AATwSAAAABIACvAIAAAAAQwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B
EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ
AJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsu
CAAAAOY+xQEAZQ7NDwDuA5UNAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwATAA8ADAQF
DQAADwAC8P0MAABAAAjwCAAAABoAAAAdEAAADwAD8JUMAAAPAATwKAAAAAEACfAQAAAAAAAAAAAA
AAAAAAAAAAAAAAIACvAIAAAAABAAAAUAAAAPAATwcgAAABIACvAIAAAAAhAAACACAABTAAvwHgAA
AH8AAAAEAIAArCUHAb8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAYABQAZAVIwIPABHwEAAAAAAA
wwsIAAAAAAAAAA0ABwEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBSAAAAQgEK8AgAAAAEEAAAAAoA
AHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgA
AAAwA1AEUASgDg8ABPBSAAAAQgEK8AgAAAAFEAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEA
ABAAwAEBAAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgAAAAAAyAKIApwDg8ABPBSAAAAQgEK8AgA
AAAGEAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywHUlAAA/wEYABgAAQIC
AAAIAAAQ8AgAAAAAA/AP8A9wDg8ABPBSAAAAQgEK8AgAAAAHEAAAAAoAAHMAC/AqAAAARAEEAAAA
fwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADwA1AEIArgBA8ABPCf
AAAAogwK8AgAAAAIEAAAAAoAAKMAC/A8AAAAgAAgHQcBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAI
gwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABAApAD9wQAAw8ADfAzAAAAAACf
DwQAAAAEAAAAAACoDwMAAABSTkMAAKEPFAAAAAQAAAAAAAAAAAAEAAAAAAACAA4ADwAE8KIAAACi
DArwCAAAAAkQAAAACgAAowAL8DwAAACAAAxABwGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAA
AAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAEACYAlCCwADDwAN8DYAAAAAAJ8PBAAA
AAQAAAAAAKgPBgAAAFJlYWRlcgAAoQ8UAAAABwAAAAAAAAAAAAcAAAAAAAIADgAPAATwnwAAAKIM
CvAIAAAAChAAAAAKAACjAAvwPAAAAIAA5EMHAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAA
CL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAQAJgD5QQAAMPAA3wMwAAAAAAnw8EAAAA
BAAAAAAAqA8DAAAAVGFnAAChDxQAAAAEAAAAAAAAAAAABAAAAAAAAgAOAA8ABPDNAAAAogwK8AgA
AAALEAAAAAoAALMAC/BCAAAABAD+bwoAgACsRwcBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA
AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADAA9AF/ghaBA8ADfBbAAAAAACfDwQA
AAAEAAAAAACoDxEAAABTZXRfUmVhZGVyX0NvbmZpZwAAoQ8UAAAAEgAAAAAAAAAAABIAAAAAAAIA
CgAAAKoPEgAAABEAAAABAAAAAwABAAAAAAAAAA8ABPBSAAAAQgEK8AgAAAAMEAAAQAoAAHMAC/Aq
AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABwBVAE
IArQBQ8ABPDKAAAAogwK8AgAAAANEAAAAAoAAJMAC/A2AAAABABei/v/gABITAcBvwACAAIAgQEE
AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAQBbAEcAmqBQ8ADfBkAAAA
AACfDwQAAAAEAAAAAACoDxoAAABTZXRfUmVhZGVyX0NvbmZpZ19SZXNwb25zZQAAoQ8UAAAAGwAA
AAAAAAAAABsAAAAAAAIACgAAAKoPEgAAABoAAAABAAAAAwABAAAAAAAAAA8ABPBSAAAAQgEK8AgA
AAAOEAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQIC
AAAIAAAQ8AgAAAAwBlAEIApQBw8ABPCrAAAAogwK8AgAAAAPEAAAAAoAALMAC/BCAAAABAD+bwoA
gADoTwcBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQIC
AAAIAAAQ8AgAAAAwBsAGewjKBg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwkAAABJbnZlbnRvcnkA
AKEPFAAAAAoAAAAAAAAAAAAKAAAAAAACAAoADwAE8FIAAABCAQrwCAAAABAQAABACgAAcwAL8CoA
AABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAALAHUAQg
ChAIDwAE8MIAAACiDArwCAAAABEQAAAACgAAkwAL8DYAAAAEAF6L+/+AAORUBwG/AAIAAgCBAQQA
AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAFAHQAUACuoHDwAN8FwAAAAA
AJ8PBAAAAAQAAAAAAKgPEgAAAEludmVudG9yeV9SZXNwb25zZQAAoQ8UAAAAEwAAAAAAAAAAABMA
AAAAAAIACgAAAKoPEgAAABIAAAABAAAAAwABAAAAAAAAAA8ABPBeAAAAQgEK8AgAAAASEAAAAAoA
AJMAC/A2AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIzgEGAAAA0AEBAAAA0QEBAAAA/wEYABgA
AQICAAAIAAAQ8AgAAACAByAK8A+ABw8ABPBeAAAAQgEK8AgAAAAVEAAAAAoAAJMAC/A2AAAARAEE
AAAAfwEAAAEAvwEAABAAwAEBAAAIzgEGAAAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgA
AACwByAK8A+wBw8ABPBeAAAAQgEK8AgAAAAWEAAAAAoAAJMAC/A2AAAARAEEAAAAfwEAAAEAvwEA
ABAAwAEBAAAIzgEGAAAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADgByAK8A/gBw8A
BPBeAAAAQgEK8AgAAAAXEAAAAAoAAJMAC/A2AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIzgEG
AAAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAAAQCCAK8A8QCA8ABPBeAAAAQgEK8AgA
AAAYEAAAAAoAAJMAC/A2AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIzgEGAAAA0AEBAAAA0QEB
AAAA/wEYABgAAQICAAAIAAAQ8AgAAABACCAK8A9ACA8ABPBeAAAAQgEK8AgAAAAZEAAAAAoAAJMA
C/A2AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIzgEGAAAA0AEBAAAA0QEBAAAA/wEYABgAAQIC
AAAIAAAQ8AgAAABwCCAK8A9wCA8ABPBeAAAAQgEK8AgAAAAaEAAAAAoAAJMAC/A2AAAARAEEAAAA
fwEAAAEAvwEAABAAwAEBAAAIzgEGAAAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAACg
CCAK8A+gCA8ABPBeAAAAQgEK8AgAAAAbEAAAAAoAAJMAC/A2AAAARAEEAAAAfwEAAAEAvwEAABAA
wAEBAAAIzgEGAAAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADQCCAK8A/QCA8ABPBS
AAAAQgEK8AgAAAAcEAAAQAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA
/wEYABgAAQICAAAIAAAQ8AgAAAAwCVAEIAqQCQ8ABPDHAAAAogwK8AgAAAAdEAAAAAoAAJMAC/A2
AAAABABei/v/gADEWgcBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI
AAAQ8AgAAADQCBAF0AlqCQ8ADfBhAAAAAACfDwQAAAAEAAAAAACoDxcAAABJbnZlbnRvcnlfQWNj
ZXNzX1JlcG9ydAAAoQ8UAAAAGAAAAAAAAAAAABgAAAAAAAIACgAAAKoPEgAAABcAAAABAAAAAwAB
AAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABEAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sA
lAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+Dj
ADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT
EAAAAAAA6y4IAAAA5z7FAYBVfCUPAO4DnR0AAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAH
ABMADwAMBA0dAAAPAALwBR0AAFAACPAIAAAANwAAADkUAAAPAAPwnRwAAA8ABPAoAAAAAQAJ8BAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAFAAABQAAAA8ABPByAAAAEgAK8AgAAAACFAAAIAIA
AFMAC/AeAAAAfwAAAAQAgACgYwcBvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBUAAw8A
EfAQAAAAAADDCwgAAAAAAAAADQAHAQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAA
AAMUAAAgAgAAUwAL8B4AAAB/AAAABACAAHRkBwG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAADAD
UAGQFWAGDwAR8BAAAAAAAMMLCAAAAAEAAAAOAAcBDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwWAAA
ABIACvAIAAAABBQAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BCAAIAAECAgAACAAAEPAIAAAAgAeABFAQIA0PAATwWAAAABIACvAIAAAABRQAAAAKAACD
AAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAA
EPAIAAAAgAeABFAQcAgPAATwTAAAAEIBCvAIAAAABhQAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAAB
AL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAgAegBaAFcAgPAATwTAAAAEIBCvAIAAAA
BxQAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAI
AAAAgAfwBvAGcAgPAATwTAAAAEIBCvAIAAAACBQAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8B
AAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAgAcgCiAKcAgPAATwvQAAAKIMCvAIAAAACRQA
AAAKAACjAAvwPAAAAIAA1GcHAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BAAAIAAECAgAACAAAEPAIAAAAsAdwBQ8HSggPAA3wUQAAAAAAnw8EAAAABAAAAAAAqA8H
AAAAVmVyPTB4MQAAoQ8UAAAACAAAAAAAAAAAAAgAAAAAAAIACgAAAKoPEgAAAAMAAAABAAAAAwAF
AAAAAAAAAA8ABPCkAAAAogwK8AgAAAAKFAAAAAoAAKMAC/A8AAAAgADMbAcBhQACAAAAhwAGAAAA
vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACwB4AHVAlK
CA8ADfA4AAAAAACfDwQAAAAEAAAAAACoDwgAAABUeXBlPTB4MgAAoQ8UAAAACQAAAAAAAAAAAAkA
AAAAAAIACgAPAATwpwAAAKIMCvAIAAAACxQAAAAKAACjAAvwPAAAAIAAiGsHAYUAAgAAAIcABgAA
AL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAsAdAC4EN
SggPAA3wOwAAAAAAnw8EAAAABAAAAAAAqA8LAAAATGVuZ3RoPTB4MTcAAKEPFAAAAAwAAAAAAAAA
AAAMAAAAAAACAAoADwAE8FgAAAASAArwCAAAAAwUAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACB
AQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAHAIgARQEGAJDwAE8EwA
AABCAQrwCAAAAA0UAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAAB
AgIAAAgAABDwCAAAAHAIIAogCmAJDwAE8NYAAACiDArwCAAAAA4UAAAACgAAowAL8DwAAACAACRv
BwGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA
ABDwCAAAAKAIQAW4CToJDwAN8GoAAAAAAJ8PBAAAAAQAAAAAAKgPGAAAAE1lc3NhZ2UgU2VxIE51
bSA9IDB4Mjc4MgAAoQ8UAAAAGQAAAAAAAAAAABkAAAAAAAIACgAAAKoPGgAAAAgAAAAAAAAAAwAA
AAEAAAADAA4AAAAAAAAADwAE8J8AAACiDArwCAAAAA8UAAAACgAAowAL8DwAAACAAGh5BwGFAAIA
AACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAA
AKAIwAzZDToJDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFJGVQAAoQ8UAAAABAAAAAAAAAAA
AAQAAAAAAAIACgAPAATwWAAAABIACvAIAAAAEBQAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB
BAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAYAmABFAQUAoPAATwWAAA
ABIACvAIAAAAERQAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BCAAIAAECAgAACAAAEPAIAAAAUAqABFAQQAsPAATwTAAAAEIBCvAIAAAAEhQAAAAKAABj
AAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAYAkgCiAK
UAoPAATwTAAAAEIBCvAIAAAAExQAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAA
CP8BGAAYAAECAgAACAAAEPAIAAAAUAogCiAKQAsPAATwnwAAAKIMCvAIAAAAFBQAAAAKAACjAAvw
PAAAAIAAVDgHAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAI
AAECAgAACAAAEPAIAAAAsAeABJkFSggPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUkZVAACh
DxQAAAAEAAAAAAAAAAAABAAAAAAAAgAKAA8ABPBMAAAAQgEK8AgAAAAVFAAAAAoAAGMAC/AkAAAA
RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAABgCXAFcAVQCg8ABPBM
AAAAQgEK8AgAAAAWFAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgA
AQICAAAIAAAQ8AgAAABgCfAG8AZQCg8ABPCeAAAAogwK8AgAAAAXFAAAAAoAAKMAC/A8AAAAgACw
gQcBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI
AAAQ8AgAAACQCYAETAUqCg8ADfAyAAAAAACfDwQAAAAEAAAAAACoDwIAAAAwMAAAoQ8UAAAAAwAA
AAAAAAAAAAMAAAAAAAIACgAPAATwnwAAAKIMCvAIAAAAGBQAAAAKAACjAAvwPAAAAIAADIUHAYUA
AgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAI
AAAAkAlwBYkGKgoPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUkZVAAChDxQAAAAEAAAAAAAA
AAAABAAAAAAAAgAKAA8ABPClAAAAogwK8AgAAAAZFAAAAAoAAKMAC/A8AAAAgAAciAcBhQACAAAA
hwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACQ
CYAHgAkqCg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwkAAABUeXBlPTB4MTIAAKEPFAAAAAoAAAAA
AAAAAAAKAAAAAAACAAoADwAE8KYAAACiDArwCAAAABoUAAAACgAAowAL8DwAAACAAKSMBwGFAAIA
AACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAA
AJAJQAtVDSoKDwAN8DoAAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAExlbmd0aD0weDgAAKEPFAAAAAsA
AAAAAAAAAAALAAAAAAACAAoADwAE8EwAAABCAQrwCAAAABsUAAAACgAAYwAL8CQAAABEAQQAAAB/
AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAFAK8AbwBkALDwAE8L0AAACiDArw
CAAAABwUAAAACgAAowAL8DwAAACAADSRBwGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/
AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAIAKEAWYBhoLDwAN8FEAAAAAAJ8PBAAAAAQA
AAAAAKgPBwAAAEFudElkPTEAAKEPFAAAAAgAAAAAAAAAAAAIAAAAAAACAAoAAACqDxIAAAAFAAAA
AQAAAAMAAwAAAAAAAAAPAATwxAAAAKIMCvAIAAAAHRQAAAAKAACjAAvwPAAAAIAAqJUHAYUAAgAA
AIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA
gArwBr0JGgsPAA3wWAAAAAAAnw8EAAAABAAAAAAAqA8OAAAAVFhQb3dlciA9IDB4RkYAAKEPFAAA
AA8AAAAAAAAAAAAPAAAAAAACAAoAAACqDxIAAAAHAAAAAQAAAAMACAAAAAAAAAAPAATwTAAAAEIB
CvAIAAAAHhQAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAA
CAAAEPAIAAAAYAlgBmAGUAoPAATwnwAAAKIMCvAIAAAAHxQAAAAKAACjAAvwPAAAAIAA2JkHAYUA
AgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAI
AAAAkAkwBjQHKgoPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUz0xAAChDxQAAAAEAAAAAAAA
AAAABAAAAAAAAgAKAA8ABPDBAAAAogwK8AgAAAAgFAAAAAoAAKMAC/A8AAAAgAC0nQcBhQACAAAA
hwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACA
ClAKdwwaCw8ADfBVAAAAAACfDwQAAAAEAAAAAACoDwsAAABGaFNlcUlkID0gMAAAoQ8UAAAADAAA
AAAAAAAAAAwAAAAAAAIACgAAAKoPEgAAAAcAAAABAAAAAwAFAAAAAAAAAA8ABPBMAAAAQgEK8AgA
AAAhFAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ
8AgAAABQCvAM8AxACw8ABPCfAAAAogwK8AgAAAAiFAAAAAoAAKMAC/A8AAAAgADkoQcBhQACAAAA
hwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACA
CuAN+Q4aCw8ADfAzAAAAAACfDwQAAAAEAAAAAACoDwMAAABSRlUAAKEPFAAAAAQAAAAAAAAAAAAE
AAAAAAACAAoADwAE8FgAAABCAQrwCAAAACMUAAAACgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAA
EADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAGAJ4BDgEEALDwAE8LsAAACi
DArwCAAAACQUAAAACgAAowAL8DwAAACAAGScBwGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAA
AAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAKYJEBGYE4wKDwAN8E8AAAAAAJ8PBAAA
AAQAAAAAAKgPHQAAAFJGIFRyYW5zbWl0dGVyIA0gICAgUGFyYW1ldGVyAAChDxYAAAAeAAAAAAAA
AAAAHgAAAAEAAgABAAkADwAE8FgAAAASAArwCAAAACUUAAAACgAAgwAL8DAAAACFAAIAAACHAAEA
AACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAEALgARQEDAMDwAE
8KUAAACiDArwCAAAACYUAAAACgAAowAL8DwAAACAAJSpBwGFAAIAAACHAAYAAAC/AAIAAgCBAQQA
AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHALgAeJCQoMDwAN8DkAAAAA
AJ8PBAAAAAQAAAAAAKgPCQAAAFR5cGU9MHhBMQAAoQ8UAAAACgAAAAAAAAAAAAoAAAAAAAIACgAP
AATwTAAAAEIBCvAIAAAAJxQAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8B
GAAYAAECAgAACAAAEPAIAAAAQAsgCiAKMAwPAATwpgAAAKIMCvAIAAAAKBQAAAAKAACjAAvwPAAA
AIAAxK0HAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC
AgAACAAAEPAIAAAAcAugC7UNCgwPAA3wOgAAAAAAnw8EAAAABAAAAAAAqA8KAAAATGVuZ3RoPTB4
OAAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIACgAPAATwTAAAAEIBCvAIAAAAKRQAAAAKAABjAAvw
JAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAQAvwBvAGMAwP
AATwTAAAAEIBCvAIAAAAKhQAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8B
GAAYAAECAgAACAAAEPAIAAAAQAtwBXAFMAwPAATwngAAAKIMCvAIAAAAKxQAAAAKAACjAAvwPAAA
AIAA9LEHAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC
AgAACAAAEPAIAAAAcAuABEwFCgwPAA3wMgAAAAAAnw8EAAAABAAAAAAAqA8CAAAAMDAAAKEPFAAA
AAMAAAAAAAAAAAADAAAAAAACAAoADwAE8J8AAACiDArwCAAAACwUAAAACgAAowAL8DwAAACAAHis
BwGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA
ABDwCAAAAHALoAW5BgoMDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFJGVQAAoQ8UAAAABAAA
AAAAAAAAAAQAAAAAAAIACgAPAATwTAAAAEIBCvAIAAAALRQAAAAKAABjAAvwJAAAAEQBBAAAAH8B
AAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAMAzwBvAGIA0PAATwpwAAAKIMCvAI
AAAALhQAAAAKAACjAAvwPAAAAIAAKLgHAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8B
AAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAYAywBNAG+gwPAA3wOwAAAAAAnw8EAAAABAAA
AAAAqA8LAAAAVHJpZ2dlcj0weDEAAKEPFAAAAAwAAAAAAAAAAAAMAAAAAAACAAoADwAE8FgAAABC
AQrwCAAAAC8UAAAACgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEA
AAD/ARgAGAABAgIAAAgAABDwCAAAAEAL4BDgECANDwAE8MMAAACiDArwCAAAADAUAAAACgAAowAL
8DwAAACAANC8BwGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAA
CAABAgIAAAgAABDwCAAAAKALQBGcFIYMDwAN8FcAAAAAAJ8PBAAAAAQAAAAAAKgPJQAAAEludmVu
dG9yeSBhbmQgQWNjZXNzDVJlcG9ydCBQYXJhbWV0ZXIAAKEPFgAAACYAAAAAAAAAAAAmAAAAAQAC
AAEACQAPAATwnwAAAKIMCvAIAAAAMRQAAAAKAACjAAvwPAAAAIAA1MAHAYUAAgAAAIcABgAAAL8A
AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAYAxgDHkN+gwP
AA3wMwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUkZVAAChDxQAAAAEAAAAAAAAAAAABAAAAAAAAgAK
AA8ABPBSAAAAQgEK8AgAAAAyFAAAgAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI
0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADwDGADsAQQDg8ABPDeAAAAogwK8AgAAAAzFAAAAAoA
AKMAC/A8AAAAgAB0xAcBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI
/wEAAAgAAQICAAAIAAAQ8AgAAAAQDvAA/AUKDw8ADfByAAAAAACfDwQAAAAEAAAAAACoD0IAAABU
cmlnZ2VyID0gMHgxID0gU2VuZCBJbnZlbnRvcnkgDXJlcG9ydCBhZnRlciBldmVyeSBpbnZlbnRv
cnkgcm91bmQAAKEPFAAAAEMAAAAAAAAAAABDAAAAAAACAAoADwAE8EwAAABCAQrwCAAAADYUAAAA
CgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAADAM
IAogCiANDwAE8KgAAACiDArwCAAAADcUAAAACgAAowAL8DwAAACAAMjIBwGFAAIAAACHAAYAAAC/
AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAGAMgAfhCfoM
DwAN8DwAAAAAAJ8PBAAAAAQAAAAAAKgPDAAAAENvbnRlbnRzPTB4MQAAoQ8UAAAADQAAAAAAAAAA
AA0AAAAAAAIACgAPAATwUgAAAEIBCvAIAAAAOBQAAMAKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8B
AAAQAMABAQAACNEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAA8AxgCVAK4A0PAATwvwAAAKIMCvAI
AAAAORQAAAAKAACjAAvwPAAAAIAAcM0HAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8B
AAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA4A0ACUUOeg4PAA3wUwAAAAAAnw8EAAAABAAA
AAAAqA8jAAAAQ29udGVudHMgPSAweDEgPSBTZW5kIG9ubHkgdGFnIGxpc3QAAKEPFAAAACQAAAAA
AAAAAAAkAAAAAAACAAoADwAE8EgAAAASAArwCAAAAAEUAAAADAAAgwAL8DAAAACBAQAAAAiDAQUA
AAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICA
AAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQA
MQAwAAAAixMQAAAAAADrLggAAADoPsUBAOD1Yw8A7gNYLQAAAgDvAxgAAAABAAAADQ4AAAAAAAAA
AACAAAAAAAcAEwAPAAwEyCwAAA8AAvDALAAAYAAI8AgAAABVAAAAaxgAAA8AA/BYLAAADwAE8CgA
AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAYAAAFAAAADwAE8HIAAAASAArwCAAA
AAIYAAAgAgAAUwAL8B4AAAB/AAAABACAACDoBwG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0A
IAFgFXACDwAR8BAAAAAAAMMLCAAAAAAAAAANAAcBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwWAAA
ABIACvAIAAAABBgAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BCAAIAAECAgAACAAAEPAIAAAAcAWwBIAQEAsPAATwWAAAABIACvAIAAAABRgAAAAKAACD
AAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAA
EPAIAAAAcAWwBIAQYAYPAATwTAAAAEIBCvAIAAAABhgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAAB
AL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAcAXQBdAFYAYPAATwTAAAAEIBCvAIAAAA
BxgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAI
AAAAcAUgByAHYAYPAATwTAAAAEIBCvAIAAAACBgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8B
AAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAcAVQClAKYAYPAATwvQAAAKIMCvAIAAAACRgA
AAAKAACjAAvwPAAAAIAAgOsHAYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BAAAIAAECAgAACAAAEPAIAAAAoAWgBT8HOgYPAA3wUQAAAAAAnw8EAAAABAAAAAAAqA8H
AAAAVmVyPTB4MQAAoQ8UAAAACAAAAAAAAAAAAAgAAAAAAAIACgAAAKoPEgAAAAMAAAABAAAAAwAF
AAAAAAAAAA8ABPClAAAAogwK8AgAAAAKGAAAAAoAAKMAC/A8AAAAgADUpqQAhQACAAAAhwAGAAAA
vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACgBbAHsAk6
Bg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwkAAABUeXBlPTB4MTAAAKEPFAAAAAoAAAAAAAAAAAAK
AAAAAAACAAoADwAE8KcAAACiDArwCAAAAAsYAAAACgAAowAL8DwAAACAAIzwBwGFAAIAAACHAAYA
AAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAKAFcAu6
DToGDwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAExlbmd0aD0weDJCAAChDxQAAAAMAAAAAAAA
AAAADAAAAAAAAgAKAA8ABPBYAAAAEgAK8AgAAAAMGAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAA
gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABgBrAEgBBQBw8ABPBM
AAAAQgEK8AgAAAANGAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgA
AQICAAAIAAAQ8AgAAABgBlAKUApQBw8ABPDWAAAAogwK8AgAAAAOGAAAAAoAAKMAC/A8AAAAgAA0
8wcBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI
AAAQ8AgAAACQBnAF6AkqBw8ADfBqAAAAAACfDwQAAAAEAAAAAACoDxgAAABNZXNzYWdlIFNlcSBO
dW0gPSAweDI3ODYAAKEPFAAAABkAAAAAAAAAAAAZAAAAAAACAAoAAACqDxoAAAAIAAAAAAAAAAMA
AAABAAAAAwAOAAAAAAAAAA8ABPCfAAAAogwK8AgAAAAPGAAAAAoAAKMAC/A8AAAAgAAY+AcBhQAC
AAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgA
AACQBvAMCQ4qBw8ADfAzAAAAAACfDwQAAAAEAAAAAACoDwMAAABSRlUAAKEPFAAAAAQAAAAAAAAA
AAAEAAAAAAACAAoADwAE8FgAAAASAArwCAAAABAYAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACB
AQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAEAIsASAEDAJDwAE8FgA
AAASAArwCAAAABEYAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADA
AQEAAAj/AQgACAABAgIAAAgAABDwCAAAADAJsASAECAKDwAE8EwAAABCAQrwCAAAABIYAAAACgAA
YwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAEAIUApQ
CjAJDwAE8EwAAABCAQrwCAAAABMYAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEA
AAj/ARgAGAABAgIAAAgAABDwCAAAADAJUApQCiAKDwAE8J8AAACiDArwCAAAABQYAAAACgAAowAL
8DwAAACAAPinpACFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAA
CAABAgIAAAgAABDwCAAAAKAFsATJBToGDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFJGVQAA
oQ8UAAAABAAAAAAAAAAAAAQAAAAAAAIACgAPAATwTAAAAEIBCvAIAAAAFRgAAAAKAABjAAvwJAAA
AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAQAhABUAFMAkPAATw
TAAAAEIBCvAIAAAAFhgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAY
AAECAgAACAAAEPAIAAAAQAggByAHMAkPAATwngAAAKIMCvAIAAAAFxgAAAAKAACjAAvwPAAAAIAA
RAE0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAA
CAAAEPAIAAAAcAiABEwFCgkPAA3wMgAAAAAAnw8EAAAABAAAAAAAqA8CAAAAMDAAAKEPFAAAAAMA
AAAAAAAAAAADAAAAAAACAAoADwAE8J8AAACiDArwCAAAABgYAAAACgAAowAL8DwAAACAAOwDNAGF
AAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDw
CAAAAHAIEAULBgoJDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEw9MAAAoQ8UAAAABAAAAAAA
AAAAAAQAAAAAAAIACgAPAATwpQAAAKIMCvAIAAAAGRgAAAAKAACjAAvwPAAAAIAA6Ac0AYUAAgAA
AIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA
cAiwB7AJCgkPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAVHlwZT0weDIzAAChDxQAAAAKAAAA
AAAAAAAACgAAAAAAAgAKAA8ABPCnAAAAogwK8AgAAAAaGAAAAAoAAKMAC/A8AAAAgACUDDQBhQAC
AAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgA
AABwCHALsQ0KCQ8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABMZW5ndGg9MHgyMAAAoQ8UAAAA
DAAAAAAAAAAAAAwAAAAAAAIACgAPAATwTAAAAEIBCvAIAAAAGxgAAAAKAABjAAvwJAAAAEQBBAAA
AH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAMAkgByAHIAoPAATwpQAAAKIM
CvAIAAAAHRgAAAAKAACjAAvwPAAAAIAAgA80AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAA
CL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAYAmwB7AJ+gkPAA3wOQAAAAAAnw8EAAAA
BAAAAAAAqA8JAAAAVHlwZT0weDE0AAChDxQAAAAKAAAAAAAAAAAACgAAAAAAAgAKAA8ABPBMAAAA
QgEK8AgAAAAeGAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQIC
AAAIAAAQ8AgAAABACAAGAAYwCQ8ABPBYAAAAEgAK8AgAAAAjGAAAAAoAAIMAC/AwAAAAhQACAAAA
hwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAAAgCrAEgBAQ
Cw8ABPBMAAAAQgEK8AgAAAAuGAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI
/wEYABgAAQICAAAIAAAQ8AgAAAAQC1AKUAoADA8ABPCQAAAAEgAK8AgAAAAwGAAAIAoAAKMAC/A8
AAAAfwABAAUAgABwEzQBgQEEAAAIgwEAAAAIvwEAABEAwAEBAAAI/wEAAAkAAQICAAAIAQMDBAAA
iAMAAAAAAAAQ8AgAAABwAvAAMBUQBQ8AEfAQAAAAAADDCwgAAAABAAAADgA0AQ8ADfAMAAAAAACe
DwQAAAABAAAADwAE8J8AAACiDArwCAAAADEYAAAACgAAowAL8DwAAACAAAQVNAGFAAIAAACHAAYA
AAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHAIAAYZ
BwoJDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFJGVQAAoQ8UAAAABAAAAAAAAAAAAAQAAAAA
AAIACgAPAATwWAAAABIACvAIAAAAMhgAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMB
AAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAEAuwBIAQAAwPAATwTAAAAEIBCvAI
AAAAMxgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAA
EPAIAAAAUAdQClAKQAgPAATwtAAAAKIMCvAIAAAANBgAAAAKAACjAAvwPAAAAIAA7Bg0AYUAAgAA
AIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA
gAcADPEPGggPAA3wSAAAAAAAnw8EAAAABAAAAAAAqA8YAAAAQWlyIFByb3RvY29sID0weDQgKEMx
RzIpAAChDxQAAAAZAAAAAAAAAAAAGQAAAAAAAgAKAA8ABPBMAAAAQgEK8AgAAAA1GAAAAAoAAGMA
C/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAABQByAHIAdA
CA8ABPCfAAAAogwK8AgAAAA2GAAAAAoAAKMAC/A8AAAAgACAHTQBhQACAAAAhwAGAAAAvwACAAIA
gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACABxAIKQkaCA8ADfAz
AAAAAACfDwQAAAAEAAAAAACoDwMAAABSRlUAAKEPFAAAAAQAAAAAAAAAAAAEAAAAAAACAAoADwAE
8L0AAACiDArwCAAAADcYAAAACgAAowAL8DwAAACAAJAhNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQA
AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAIAHEAWYBhoIDwAN8FEAAAAA
AJ8PBAAAAAQAAAAAAKgPBwAAAEFudElkPTEAAKEPFAAAAAgAAAAAAAAAAAAIAAAAAAACAAoAAACq
DxIAAAAFAAAAAQAAAAMAAwAAAAAAAAAPAATwTAAAAEIBCvAIAAAAOBgAAAAKAABjAAvwJAAAAEQB
BAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAMAlABUAFIAoPAATwngAA
AKIMCvAIAAAAORgAAAAKAACjAAvwPAAAAIAAOCY0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMB
AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAYAmABEwF+gkPAA3wMgAAAAAAnw8E
AAAABAAAAAAAqA8CAAAAMDAAAKEPFAAAAAMAAAAAAAAAAAADAAAAAAACAAoADwAE8J8AAACiDArw
CAAAADoYAAAACgAAowAL8DwAAACAAAwqNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/
AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAGAJEAUZBvoJDwAN8DMAAAAAAJ8PBAAAAAQA
AAAAAKgPAwAAAE49MQAAoQ8UAAAABAAAAAAAAAAAAAQAAAAAAAIACgAPAATwTAAAAEIBCvAIAAAA
OxgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAI
AAAAMAkABgAGIAoPAATwnwAAAKIMCvAIAAAAPBgAAAAKAACjAAvwPAAAAIAAtC00AYUAAgAAAIcA
BgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAYAkA
BhkH+gkPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUkZVAAChDxQAAAAEAAAAAAAAAAAABAAA
AAAAAgAKAA8ABPCnAAAAogwK8AgAAAA9GAAAAAoAAKMAC/A8AAAAgACAMTQBhQACAAAAhwAGAAAA
vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABgCXALsQ36
CQ8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABMZW5ndGg9MHgxMAAAoQ8UAAAADAAAAAAAAAAA
AAwAAAAAAAIACgAPAATwsgAAAKIMCvAIAAAAPhgAAAAKAACjAAvwPAAAAIAAoDU0AYUAAgAAAIcA
BgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAUApA
CL4L6goPAA3wRgAAAAAAnw8EAAAABAAAAAAAqA8WAAAAU3RhcnQgVGltZSA9MCAoaWdub3JlKQAA
oQ8UAAAAFwAAAAAAAAAAABcAAAAAAAIACgAPAATwqwAAAKIMCvAIAAAAPxgAAAAKAACjAAvwPAAA
AIAAwDk0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC
AgAACAAAEPAIAAAAQAswBtMI2gsPAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8PAAAAU3RhcnQgUm91
bmQgPSAwAAChDxQAAAAQAAAAAAAAAAAAEAAAAAAAAgAKAA8ABPCpAAAAogwK8AgAAABAGAAAAAoA
AKMAC/A8AAAAgAC4PTQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI
/wEAAAgAAQICAAAIAAAQ8AgAAABACwAMiA7aCw8ADfA9AAAAAACfDwQAAAAEAAAAAACoDw0AAABF
bmQgUm91bmQgPSAxAAChDxQAAAAOAAAAAAAAAAAADgAAAAAAAgAKAA8ABPBYAAAAEgAK8AgAAABB
GAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgA
AQICAAAIAAAQ8AgAAAAADLAEgBDwDA8ABPCnAAAAogwK8AgAAABCGAAAAAoAAIMAC/AwAAAAgACw
QjQBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAwDBAI
+wzKDA8ADfBHAAAAAACfDwQAAAAEAAAAAACoDxcAAABSb3VuZCBTaXplID0gMCAoaWdub3JlKQAA
oQ8UAAAAGAAAAAAAAAAAABgAAAAAAAIACgAPAATwWAAAABIACvAIAAAARBgAAAAKAACDAAvwMAAA
AIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA
4A2wBIAQ0A4PAATwUgAAAEIBCvAIAAAARRgAAIAKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQ
AMABAQAACNEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAA8AmQA3AFsAoPAATwpQAAAKIMCvAIAAAA
RhgAAAAKAACjAAvwPAAAAIAAqEY0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQ
AMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAsArgAaQDSgsPAA3wOQAAAAAAnw8EAAAABAAAAAAA
qA8JAAAAU3RhcnQgbm93AAChDxQAAAAKAAAAAAAAAAAACgAAAAAAAgAKAA8ABPBYAAAAEgAK8AgA
AABHGAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEI
AAgAAQICAAAIAAAQ8AgAAADwDLAEgBDgDQ8ABPBMAAAAQgEK8AgAAABIGAAAAAoAAGMAC/AkAAAA
RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAADwDFAKUArgDQ8ABPBM
AAAAQgEK8AgAAABJGAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgA
AQICAAAIAAAQ8AgAAADwDCAHIAfgDQ8ABPClAAAAogwK8AgAAABKGAAAAAoAAKMAC/A8AAAAgABo
SzQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI
AAAQ8AgAAAAgDbAHsAm6DQ8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwkAAABUeXBlPTB4MjEAAKEP
FAAAAAoAAAAAAAAAAAAKAAAAAAACAAoADwAE8EwAAABCAQrwCAAAAEsYAAAACgAAYwAL8CQAAABE
AQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAPAMQAVABeANDwAE8J4A
AACiDArwCAAAAEwYAAAACgAAowAL8DwAAACAALBPNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiD
AQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAACANgARMBboNDwAN8DIAAAAAAJ8P
BAAAAAQAAAAAAKgPAgAAADAwAAChDxQAAAADAAAAAAAAAAAAAwAAAAAAAgAKAA8ABPCfAAAAogwK
8AgAAABPGAAAAAoAAKMAC/A8AAAAgADQUzQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAI
vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAgDaAFuQa6DQ8ADfAzAAAAAACfDwQAAAAE
AAAAAACoDwMAAABSRlUAAKEPFAAAAAQAAAAAAAAAAAAEAAAAAAACAAoADwAE8KYAAACiDArwCAAA
AFAYAAAACgAAowAL8DwAAACAALxXNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA
EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAACANcAuTDboNDwAN8DoAAAAAAJ8PBAAAAAQAAAAA
AKgPCgAAAExlbmd0aD0weEMAAKEPFAAAAAsAAAAAAAAAAAALAAAAAAACAAoADwAE8FgAAAASAArw
CAAAAFEYAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/
AQgACAABAgIAAAgAABDwCAAAANAOsASAEMAPDwAE8EwAAABCAQrwCAAAAFIYAAAACgAAYwAL8CQA
AABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAOANkAmQCdAODwAE
8NYAAACiDArwCAAAAFQYAAAACgAAowAL8DwAAACAAGRSNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQA
AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAABAOgAqBDqoODwAN8GoAAAAA
AJ8PBAAAAAQAAAAAAKgPGAAAAE1vYiA9IHBvcCA9IGVudiA9IGlnbm9yZQAAoQ8UAAAAGQAAAAAA
AAAAABkAAAAAAAIACgAAAKoPGgAAAAwAAAAAAAAAAwAAAAEAAAADAAoAAAAAAAAADwAE8J8AAACi
DArwCAAAAFUYAAAACgAAowAL8DwAAACAAORfNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAA
AAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAABAOcAiCCaoODwAN8DMAAAAAAJ8PBAAA
AAQAAAAAAKgPAwAAAE09MAAAoQ8UAAAABAAAAAAAAAAAAAQAAAAAAAIACgAPAATwTAAAAEIBCvAI
AAAAVhgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAA
EPAIAAAA4A1wCHAI0A4PAATwTAAAAEIBCvAIAAAAVxgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAAB
AL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAA4A2AB4AH0A4PAATwTAAAAEIBCvAIAAAA
WBgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAI
AAAA4A3wBvAG0A4PAATwTAAAAEIBCvAIAAAAWRgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8B
AAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAA4A2gBaAF0A4PAATwnwAAAKIMCvAIAAAAWhgA
AAAKAACjAAvwPAAAAIAAKGQ0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BAAAIAAECAgAACAAAEPAIAAAAEA6ABJkFqg4PAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8D
AAAAUkZVAAChDxQAAAAEAAAAAAAAAAAABAAAAAAAAgAKAA8ABPC8AAAAogwK8AgAAABbGAAAAAoA
AKMAC/A8AAAAgACoaDQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI
/wEAAAgAAQICAAAIAAAQ8AgAAAAQDnAF8AaqDg8ADfBQAAAAAACfDwQAAAAEAAAAAACoDwYAAABT
ZXNzPTMAAKEPFAAAAAcAAAAAAAAAAAAHAAAAAAACAAoAAACqDxIAAAAEAAAAAQAAAAMAAwAAAAAA
AAAPAATwnwAAAKIMCvAIAAAAXBgAAAAKAACjAAvwPAAAAIAAlGw0AYUAAgAAAIcABgAAAL8AAgAC
AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAEA7ABqUHqg4PAA3w
MwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAST0wAAChDxQAAAAEAAAAAAAAAAAABAAAAAAAAgAKAA8A
BPCfAAAAogwK8AgAAABdGAAAAAoAAKMAC/A8AAAAgACAcDQBhQACAAAAhwAGAAAAvwACAAIAgQEE
AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAQDoAHhAiqDg8ADfAzAAAA
AACfDwQAAAAEAAAAAACoDwMAAABTPTAAAKEPFAAAAAQAAAAAAAAAAAAEAAAAAAACAAoADwAE8EwA
AABCAQrwCAAAAF4YAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAAB
AgIAAAgAABDwCAAAANAO8AbwBsAPDwAE8OwAAACiDArwCAAAAF8YAAAACgAAowAL8DwAAACAACxr
NAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA
ABDwCAAAAAAP4AfBDZoPDwAN8IAAAAAAAJ8PBAAAAAQAAAAAAKgPJAAAAFFzdGVwdXBzaXplID0g
UXN0ZXBkb3duc2l6ZSA9IGlnbm9yZQAAoQ8UAAAAJQAAAAAAAAAAACUAAAAAAAIACgAAAKoPJAAA
AAsAAAABAAAAAwADAAAAAAAAAA0AAAABAAAAAwAKAAAAAAAAAA8ABPCXAAAAogwK8AgAAABgGAAA
AAoAAIMAC/AwAAAAgADUdzQBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQIC
AAAIAAAQ8AgAAAAADxAFwAaaDw8ADfA3AAAAAACfDwQAAAAEAAAAAACoDwcAAABRID0gMTAgAACh
DxQAAAAIAAAAAAAAAAAACAAAAAAAAgAKAA8ABPBSAAAAQgEK8AgAAABiGAAAgAoAAHMAC/AqAAAA
RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAACgDmAGIAcg
EA8ABPCrAAAAogwK8AgAAABjGAAAAAoAAKMAC/A8AAAAgABEfDQBhQACAAAAhwAGAAAAvwACAAIA
gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAVEOYDbAavEA8ADfA/
AAAAAACfDwQAAAAEAAAAAACoDw8AAABUYWdzIGluIEEgc3RhdGUAAKEPFAAAABAAAAAAAAAAAAAQ
AAAAAAACAAoADwAE8K4AAACiDArwCAAAAGQYAAAACgAAowAL8DwAAACAAISANAGFAAIAAACHAAYA
AAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAEYQUAdd
CuAQDwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPEgAAAFRhZ3MgaW4gU0w9MSBzdGF0ZQAAoQ8UAAAA
EwAAAAAAAAAAABMAAAAAAAIACgAPAATwUgAAAEIBCvAIAAAAZRgAAIAKAABzAAvwKgAAAEQBBAAA
AH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAoA7gB+AHIBAPAATw
WAAAAEIBCvAIAAAAZhgAAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNABAQAA
ANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAQAgQFBAUkA8PAATwwQAAAKIMCvAIAAAAZxgAAAAK
AACjAAvwPAAAAIAAjIQ0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAA
CP8BAAAIAAECAgAACAAAEPAIAAAA8An4E5QWLAsPAA3wVQAAAAAAnw8EAAAABAAAAAAAqA8jAAAA
QzFHMiBJbnZlbnRvcnkgDUNvbW1hbmQgIA1QYXJhbWV0ZXIAAKEPFgAAACQAAAAAAAAAAAAkAAAA
AQACAAEACQAPAATwWAAAAEIBCvAIAAAAaBgAAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQ
AMABAQAACNABAQAAANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAMAngEOAQ8AwPAATwwwAAAKIM
CvAIAAAAaRgAAAAKAACjAAvwPAAAAIAArIk0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAA
CL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA8AkQEcQTLAsPAA3wVwAAAAAAnw8EAAAA
BAAAAAAAqA8lAAAASW52ZW50b3J5IA1PcGVyYXRpb24gdGltaW5nDVBhcmFtZXRlcgAAoQ8WAAAA
JgAAAAAAAAAAACYAAAABAAIAAQAJAA8ABPBYAAAAQgEK8AgAAABqGAAAAAoAAIMAC/AwAAAARAEE
AAAAfwEAAAEAvwEAABAAwAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADADOAQ
4BDADw8ABPDbAAAAogwK8AgAAABrGAAAAAoAAKMAC/A8AAAAgABIjjQBhQACAAAAhwAGAAAAvwAC
AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABQDRARDBOMDg8A
DfBvAAAAAACfDwQAAAAEAAAAAACoDxsAAABDMUcyIA1TaW5ndWxhdGlvbg1QYXJhbWV0ZXIAAKEP
FgAAABwAAAAAAAAAAAAcAAAAAQACAAEACQAAAKoPGgAAAAYAAAAAAAAACwAAAAEAAAADAAsAAAAA
AAAADwAE8EgAAAASAArwCAAAAAEYAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69
aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZ
AACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAA
AADrLggAAAD4PsUB0I6Szg8A7gO8JwAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAP
AAwELCcAAA8AAvAkJwAAcAAI8AgAAABLAAAAoRwAAA8AA/C8JgAADwAE8CgAAAABAAnwEAAAAAAA
AAAAAAAAAAAAAAAAAAACAArwCAAAAAAcAAAFAAAADwAE8HgAAAASAArwCAAAAAIcAAAgAgAAYwAL
8CQAAAB/AAAABACAADCeNAG/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAGAAIAFgFSMC
DwAR8BAAAAAAAMMLCAAAAAAAAAANADQBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwWAAAABIACvAI
AAAAAxwAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B
CAAIAAECAgAACAAAEPAIAAAAwAOwBIAQsAcPAATwWAAAABIACvAIAAAABBwAAAAKAACDAAvwMAAA
AIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA
wAOwBIAQUAQPAATwTAAAAEIBCvAIAAAABRwAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQ
AMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAwAPQBdAFUAQPAATwTAAAAEIBCvAIAAAABhwAAAAK
AABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAwAMg
ByAHUAQPAATwTAAAAEIBCvAIAAAABxwAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMAB
AQAACP8BGAAYAAECAgAACAAAEPAIAAAAwANQClAKsAQPAATwvQAAAKIMCvAIAAAACBwAAAAKAACj
AAvwPAAAAIAA/KA0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B
AAAIAAECAgAACAAAEPAIAAAAwAOgBT8HWgQPAA3wUQAAAAAAnw8EAAAABAAAAAAAqA8HAAAAVmVy
PTB4MQAAoQ8UAAAACAAAAAAAAAAAAAgAAAAAAAIACgAAAKoPEgAAAAMAAAABAAAAAwAFAAAAAAAA
AA8ABPClAAAAogwK8AgAAAAJHAAAAAoAAKMAC/A8AAAAgACYpDQBhQACAAAAhwAGAAAAvwACAAIA
gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADAA7AHsAlaBA8ADfA5
AAAAAACfDwQAAAAEAAAAAACoDwkAAABUeXBlPTB4MjAAAKEPFAAAAAoAAAAAAAAAAAAKAAAAAAAC
AAoADwAE8KcAAACiDArwCAAAAAocAAAACgAAowAL8DwAAACAAFihNAGFAAIAAACHAAYAAAC/AAIA
AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAMADcAuxDVoEDwAN
8DsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAExlbmd0aD0weDQ3AAChDxQAAAAMAAAAAAAAAAAADAAA
AAAAAgAKAA8ABPBYAAAAEgAK8AgAAAALHAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAI
gwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABQBLAEgBDgBA8ABPBMAAAAQgEK
8AgAAAAMHAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAI
AAAQ8AgAAACwBFAKUApwBQ8ABPDRAAAAogwK8AgAAAANHAAAAAoAAKMAC/A8AAAAgACYrDQBhQAC
AAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgA
AABQBHAFEAnqBA8ADfBlAAAAAACfDwQAAAAEAAAAAACoDxMAAABNZXNzYWdlIFNlcSBOdW0gPSAw
AAChDxQAAAAUAAAAAAAAAAAAFAAAAAAAAgAKAAAAqg8aAAAACAAAAAAAAAADAAAAAQAAAAMACQAA
AAAAAAAPAATwnwAAAKIMCvAIAAAADhwAAAAKAACjAAvwPAAAAIAAYLE0AYUAAgAAAIcABgAAAL8A
AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAUATwDAkO6gQP
AA3wMwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUkZVAAChDxQAAAAEAAAAAAAAAAAABAAAAAAAAgAK
AA8ABPBYAAAAEgAK8AgAAAAPHAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAI
vwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADgBLAEgBBwBQ8ABPBYAAAAEgAK8AgAAAAQ
HAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgA
AQICAAAIAAAQ8AgAAACQBrAEgBAgBw8ABPBMAAAAQgEK8AgAAAARHAAAAAoAAGMAC/AkAAAARAEE
AAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAAAQBVAKUApwBQ8ABPCfAAAA
ogwK8AgAAAATHAAAAAoAAKMAC/A8AAAAgABgrjQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA
AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADAA7AEyQVaBA8ADfAzAAAAAACfDwQA
AAAEAAAAAACoDwMAAABSRlUAAKEPFAAAAAQAAAAAAAAAAAAEAAAAAAACAAoADwAE8EwAAABCAQrw
CAAAABQcAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgA
ABDwCAAAAOAEcAVwBXAFDwAE8EwAAABCAQrwCAAAABUcAAAACgAAYwAL8CQAAABEAQQAAAB/AQAA
AQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAOAEIAcgB3AFDwAE8J4AAACiDArwCAAA
ABYcAAAACgAAowAL8DwAAACAACywNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA
EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAOAEsAR8BXoFDwAN8DIAAAAAAJ8PBAAAAAQAAAAA
AKgPAgAAADAwAAChDxQAAAADAAAAAAAAAAAAAwAAAAAAAgAKAA8ABPClAAAAogwK8AgAAAAYHAAA
AAoAAKMAC/A8AAAAgABkvDQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEB
AAAI/wEAAAgAAQICAAAIAAAQ8AgAAADgBOAH6Ql6BQ8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwkA
AABUeXBlPTB4QTQAAKEPFAAAAAoAAAAAAAAAAAAKAAAAAAACAAoADwAE8KcAAACiDArwCAAAABkc
AAAACgAAowAL8DwAAACAAJDBNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADA
AQEAAAj/AQAACAABAgIAAAgAABDwCAAAAOAEoAvhDXoFDwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgP
CwAAAExlbmd0aD0weDE0AAChDxQAAAAMAAAAAAAAAAAADAAAAAAAAgAKAA8ABPCQAAAAEgAK8AgA
AAAfHAAAIAoAAKMAC/A8AAAAfwABAAUAgACYwzQBgQEEAAAIgwEAAAAIvwEAABEAwAEBAAAI/wEA
AAkAAQICAAAIAQMDBAAAiAMAAAAAAAAQ8AgAAADgASABYBWQAw8AEfAQAAAAAADDCwgAAAABAAAA
DgA0AQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8J8AAACiDArwCAAAACAcAAAACgAAowAL8DwAAACA
AATFNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA
AAgAABDwCAAAAOAE0AXpBnoFDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFJGVQAAoQ8UAAAA
BAAAAAAAAAAAAAQAAAAAAAIACgAPAATwpwAAAKIMCvAIAAAAURwAAAAKAACjAAvwPAAAAIAAFMg0
AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAA
EPAIAAAAkAYwCTULKgcPAA3wOwAAAAAAnw8EAAAABAAAAAAAqA8LAAAAVGFnIDFbMDozMV0AAKEP
FAAAAAwAAAAAAAAAAAAMAAAAAAACAAoADwAE8KgAAACiDArwCAAAAFIcAAAACgAAowAL8DwAAACA
AJzMNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA
AAgAABDwCAAAACAHMAlhC7oHDwAN8DwAAAAAAJ8PBAAAAAQAAAAAAKgPDAAAAFRhZyAxWzMyOjYz
XQAAoQ8UAAAADQAAAAAAAAAAAA0AAAAAAAIACgAPAATwWAAAABIACvAIAAAAUxwAAAAKAACDAAvw
MAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAI
AAAAYAmwBIAQgAoPAATw6gAAAKIMCvAIAAAAcBwAAAAKAACjAAvwPAAAAIAALNE0AYUAAgAAAIcA
BgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA0AjX
EYAW1goPAA3wfgAAAAAAnw8EAAAABAAAAAAAqA9OAAAASW4gdGhpcyBleGFtcGxlLCANMyB0YWdz
IGFyZSBzZWVuDWJ5IHRoZSByZWFkZXI7IA0yIDY0IGJpdCB0YWdzLCAxIDk2IGJpdCB0YWcuAACh
DxQAAABPAAAAAAAAAAAATwAAAAAAAgAMAA8ABPBYAAAAQgEK8AgAAABxHAAAAAoAAIMAC/AwAAAA
RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABw
BQADAANACA8ABPCwAAAAogwK8AgAAAByHAAAAAoAAKMAC/A8AAAAgAB01jQBhQACAAAAhwAGAAAA
vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAwBpAAZAIW
Bw8ADfBEAAAAAACfDwQAAAAEAAAAAACoDxIAAABUYWcgRGF0YQ1QYXJhbWV0ZXIAAKEPFgAAABMA
AAAAAAAAAAATAAAAAQACAAEACQAPAATwWAAAABIACvAIAAAAdhwAAAAKAACDAAvwMAAAAIUAAgAA
AIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAAAawBIAQ
kAYPAATwqgAAAKIMCvAIAAAAdxwAAAAKAACjAAvwPAAAAIAA2No0AYUAAgAAAIcABgAAAL8AAgAC
AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAcAUACbcLCgYPAA3w
PgAAAAAAnw8EAAAABAAAAAAAqA8OAAAAVGltZXN0YW1wID0gVDEAAKEPFAAAAA8AAAAAAAAAAAAP
AAAAAAACAAoADwAE8EwAAABCAQrwCAAAAHgcAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAA
EADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAAAGUApQCpAGDwAE8KUAAACiDArwCAAAAHkcAAAA
CgAAowAL8DwAAACAAPzUNAGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEA
AAj/AQAACAABAgIAAAgAABDwCAAAAAAG0AW/B5oGDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPCQAA
AFJTU0kgPSBSMQAAoQ8UAAAACgAAAAAAAAAAAAoAAAAAAAIACgAPAATwnwAAAKIMCvAIAAAAehwA
AAAKAACjAAvwPAAAAIAALOE0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BAAAIAAECAgAACAAAEPAIAAAAAAaQDKkNmgYPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8D
AAAAUkZVAAChDxQAAAAEAAAAAAAAAAAABAAAAAAAAgAKAA8ABPBMAAAAQgEK8AgAAAB7HAAAAAoA
AGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAACAB1AK
UApACA8ABPBYAAAAEgAK8AgAAAB8HAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEA
AAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACwB7AEgBBACA8ABPBYAAAAEgAK8AgA
AAB9HAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEI
AAgAAQICAAAIAAAQ8AgAAABgCbAEgBDwCQ8ABPBMAAAAQgEK8AgAAAB+HAAAAAoAAGMAC/AkAAAA
RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAADgB1AKUApACA8ABPBM
AAAAQgEK8AgAAAB/HAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgA
AQICAAAIAAAQ8AgAAACwB3AFcAVACA8ABPBMAAAAQgEK8AgAAACAHAAAAAoAAGMAC/AkAAAARAEE
AAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAACwByAHIAdACA8ABPCeAAAA
ogwK8AgAAACBHAAAAAoAAKMAC/A8AAAAgADk5jQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA
AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACwB7AEfAVKCA8ADfAyAAAAAACfDwQA
AAAEAAAAAACoDwIAAAAwMAAAoQ8UAAAAAwAAAAAAAAAAAAMAAAAAAAIACgAPAATwpQAAAKIMCvAI
AAAAghwAAAAKAACjAAvwPAAAAIAA9Ok0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8B
AAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAsAfgB+kJSggPAA3wOQAAAAAAnw8EAAAABAAA
AAAAqA8JAAAAVHlwZT0weEE0AAChDxQAAAAKAAAAAAAAAAAACgAAAAAAAgAKAA8ABPCnAAAAogwK
8AgAAACDHAAAAAoAAKMAC/A8AAAAgADcyTQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAI
vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACwB6AL4Q1KCA8ADfA7AAAAAACfDwQAAAAE
AAAAAACoDwsAAABMZW5ndGg9MHgxNAAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAIACgAPAATwnwAA
AKIMCvAIAAAAhBwAAAAKAACjAAvwPAAAAIAATPE0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMB
AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAsAfQBekGSggPAA3wMwAAAAAAnw8E
AAAABAAAAAAAqA8DAAAAUkZVAAChDxQAAAAEAAAAAAAAAAAABAAAAAAAAgAKAA8ABPCnAAAAogwK
8AgAAACFHAAAAAoAAKMAC/A8AAAAgADs9DQBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAI
vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABgCTAJNQv6CQ8ADfA7AAAAAACfDwQAAAAE
AAAAAACoDwsAAABUYWcgMlswOjMxXQAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAIACgAPAATwqAAA
AKIMCvAIAAAAhhwAAAAKAACjAAvwPAAAAIAA6Pk0AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMB
AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA8AkwCWELigoPAA3wPAAAAAAAnw8E
AAAABAAAAAAAqA8MAAAAVGFnIDJbMzI6NjNdAAChDxQAAAANAAAAAAAAAAAADQAAAAAAAgAKAA8A
BPBYAAAAEgAK8AgAAACHHAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEA
ABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADQCLAEgBBgCQ8ABPCqAAAAogwK8AgAAACIHAAA
AAoAAKMAC/A8AAAAgADMADUBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEB
AAAI/wEAAAgAAQICAAAIAAAQ8AgAAABACAAJtwvaCA8ADfA+AAAAAACfDwQAAAAEAAAAAACoDw4A
AABUaW1lc3RhbXAgPSBUMgAAoQ8UAAAADwAAAAAAAAAAAA8AAAAAAAIACgAPAATwTAAAAEIBCvAI
AAAAiRwAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAA
EPAIAAAA0AhQClAKYAkPAATwpQAAAKIMCvAIAAAAihwAAAAKAACjAAvwPAAAAIAAOAQ1AYUAAgAA
AIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA
0AjQBb8HagkPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAUlNTSSA9IFIyAAChDxQAAAAKAAAA
AAAAAAAACgAAAAAAAgAKAA8ABPCfAAAAogwK8AgAAACLHAAAAAoAAKMAC/A8AAAAgAA0CTUBhQAC
AAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgA
AADQCJAMqQ1qCQ8ADfAzAAAAAACfDwQAAAAEAAAAAACoDwMAAABSRlUAAKEPFAAAAAQAAAAAAAAA
AAAEAAAAAAACAAoADwAE8FgAAAASAArwCAAAAIwcAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACB
AQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAEAIsASAENAIDwAE8FgA
AAASAArwCAAAAI0cAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADA
AQEAAAj/AQgACAABAgIAAAgAABDwCAAAADAMsASAEFANDwAE8EwAAABCAQrwCAAAAI4cAAAACgAA
YwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAFAKUApQ
ChALDwAE8FgAAAASAArwCAAAAI8cAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAA
AAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAIAKsASAEBALDwAE8FgAAAASAArwCAAA
AJAcAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgA
CAABAgIAAAgAABDwCAAAADAMsASAEMAMDwAE8EwAAABCAQrwCAAAAJEcAAAACgAAYwAL8CQAAABE
AQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAALAKUApQChALDwAE8EwA
AABCAQrwCAAAAJIcAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAAB
AgIAAAgAABDwCAAAAIAKcAVwBRALDwAE8EwAAABCAQrwCAAAAJMcAAAACgAAYwAL8CQAAABEAQQA
AAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAIAKIAcgBxALDwAE8J4AAACi
DArwCAAAAJQcAAAACgAAowAL8DwAAACAANwONQGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAA
AAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAIAKsAR8BRoLDwAN8DIAAAAAAJ8PBAAA
AAQAAAAAAKgPAgAAADAwAAChDxQAAAADAAAAAAAAAAAAAwAAAAAAAgAKAA8ABPClAAAAogwK8AgA
AACVHAAAAAoAAKMAC/A8AAAAgABMEjUBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEA
ABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACACuAH6QkaCw8ADfA5AAAAAACfDwQAAAAEAAAA
AACoDwkAAABUeXBlPTB4QTQAAKEPFAAAAAoAAAAAAAAAAAAKAAAAAAACAAoADwAE8KcAAACiDArw
CAAAAJYcAAAACgAAowAL8DwAAACAAHAONQGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/
AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAIAKoAvhDRoLDwAN8DsAAAAAAJ8PBAAAAAQA
AAAAAKgPCwAAAExlbmd0aD0weDE4AAChDxQAAAAMAAAAAAAAAAAADAAAAAAAAgAKAA8ABPCfAAAA
ogwK8AgAAACXHAAAAAoAAKMAC/A8AAAAgACUGjUBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA
AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACACtAF6QYaCw8ADfAzAAAAAACfDwQA
AAAEAAAAAACoDwMAAABSRlUAAKEPFAAAAAQAAAAAAAAAAAAEAAAAAAACAAoADwAE8KcAAACiDArw
CAAAAJgcAAAACgAAowAL8DwAAACAACQfNQGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/
AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAADAMMAk1C8oMDwAN8DsAAAAAAJ8PBAAAAAQA
AAAAAKgPCwAAAFRhZyAzWzA6MzFdAAChDxQAAAAMAAAAAAAAAAAADAAAAAAAAgAKAA8ABPCoAAAA
ogwK8AgAAACZHAAAAAoAAKMAC/A8AAAAgADIITUBhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA
AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADADDAJYQtaDQ8ADfA8AAAAAACfDwQA
AAAEAAAAAACoDwwAAABUYWcgM1szMjo2M10AAKEPFAAAAA0AAAAAAAAAAAANAAAAAAACAAoADwAE
8FgAAAASAArwCAAAAJocAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAA
EADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAKALsASAEDAMDwAE8KoAAACiDArwCAAAAJscAAAA
CgAAowAL8DwAAACAAAgmNQGFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEA
AAj/AQAACAABAgIAAAgAABDwCAAAABALAAm3C6oLDwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKgPDgAA
AFRpbWVzdGFtcCA9IFQzAAChDxQAAAAPAAAAAAAAAAAADwAAAAAAAgAKAA8ABPBMAAAAQgEK8AgA
AACcHAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ
8AgAAACgC1AKUAowDA8ABPClAAAAogwK8AgAAACdHAAAAAoAAKMAC/A8AAAAgACcKjUBhQACAAAA
hwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACg
C9AFvwc6DA8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwkAAABSU1NJID0gUjMAAKEPFAAAAAoAAAAA
AAAAAAAKAAAAAAACAAoADwAE8J8AAACiDArwCAAAAJ4cAAAACgAAowAL8DwAAACAAOguNQGFAAIA
AACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAA
AKALkAypDToMDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFJGVQAAoQ8UAAAABAAAAAAAAAAA
AAQAAAAAAAIACgAPAATwWAAAABIACvAIAAAAnxwAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB
BAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAEAuwBIAQoAsPAATwWAAA
ABIACvAIAAAAoBwAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMAB
AQAACP8BCAAIAAECAgAACAAAEPAIAAAAUA2wBIAQ4A0PAATwqAAAAKIMCvAIAAAAoRwAAAAKAACj
AAvwPAAAAIAALDM1AYUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B
AAAIAAECAgAACAAAEPAIAAAAUA0wCWEL6g0PAA3wPAAAAAAAnw8EAAAABAAAAAAAqA8MAAAAVGFn
IDNbNjQ6OTVdAAChDxQAAAANAAAAAAAAAAAADQAAAAAAAgAKAA8ABPBIAAAAEgAK8AgAAAABHAAA
AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB
AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAA
AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAA+D7FAdCOks4AAHIXJAAA
AAEAgAAAAAAAyQgAAHUSAAAnFAAAUxYAAPAjAACVQQAA9W4AAAAA9Q8cAAAAAwEAAD8KAAMAAAAA
uZYAAAEAAAAIAAAAAQCeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYA
AAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAP7///8QAAAAEQAAABIAAAATAAAAFAAA
ABUAAAAWAAAAFwAAABgAAAD+////GgAAAP7/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////7/AAAFAQIAAAAAAAAAAAAAAAAAAAAA
AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAFQDAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAACAAAAA
CAAAAJAAAAAJAAAAqAAAABIAAAC0AAAACgAAANgAAAAMAAAA5AAAAA0AAADwAAAADwAAAPwAAAAR
AAAABAEAAAIAAADkBAAAHgAAAA4AAABTTFJSUCBFeGFtcGxlAGYAHgAAAAcAAAB0Y2Fib3QAeB4A
AAAQAAAAS2F2aXRoYSBLcmlzaG5hAB4AAAADAAAAMTMAaR4AAAAcAAAATWljcm9zb2Z0IE9mZmlj
ZSBQb3dlclBvaW50AEAAAADgzSgEGwAAAEAAAAAgJPwO5z7FAUAAAAAAw6S0VnrFAQMAAAAYAQAA
RwAAAEYCAAD/////AwAAAAgAiRBnDAAAAQAJAAADGwEAAAUAJwAAAAAABAAAAAMBCAAFAAAACwIA
AAAABQAAAAwC7wLpAwMAAAAeAAcAAAD8AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAAAAAD///8A
BAAAAC0BAQAMAAAAQAkhAPAAAAAAAAAA7wLpA/////8IAAAA+gIAAAAAAAAAAAAABAAAAC0BAgAE
AAAALQEAAAQAAAAnAf//HAAAAPsCw/8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACJwAAADIKRQGw
ABUAAABTTFJSUCBDMUcyIEludmVudG9yeSAAKQAiACwALAApABEALAAiAC8AIgASABAAIgAfACIA
IgARACIAFQAdABIABAAAAC4BAAAcAAAA+wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0AAAAAAAAY
AAAA6OcTAAEAAADkBAAAAAAAAAQAAAAtAQQABAAAAPABAwAcAAAA+wLD/wAAAAAAAJABAAAAAABA
AABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEB
AAUAAAAJAgAAAAISAAAAMgqOAX0BBwAAAEV4YW1wbGUAKQAeACIAMwAiAA4AIgAEAAAALgEAAAQA
AAAtAQQABAAAAPABAwADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3V
nC4bEJOXCAArLPmuMAAAACgCAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAAMAAAAAG
AAAAyAAAAAcAAADQAAAACAAAANgAAAAJAAAA4AAAAAoAAADoAAAAFwAAAPAAAAALAAAA+AAAABAA
AAAAAQAAEwAAAAgBAAAWAAAAEAEAAA0AAAAYAQAADAAAAMUBAAACAAAA5AQAAB4AAAAPAAAAT24t
c2NyZWVuIFNob3cAAB4AAAANAAAAUmV2YSBTeXN0ZW1zAHcAAAMAAAAJlwAAAwAAAIwAAAADAAAA
BgAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAABBCgoACwAAAAAAAAALAAAAAAAAAAsAAAAA
AAAACwAAAAAAAAAeEAAACAAAAAYAAABBcmlhbAAPAAAARGVmYXVsdCBEZXNpZ24AHQAAAFNMUlJQ
IEMxRzIgSW52ZW50b3J5IEV4YW1wbGUACgAAAFVzZUNhc2UgMQAJAAAAVGltZWxpbmUAEgAAAFNl
dF9SZWFkZXJfQ29uZmlnABIAAABJbnZlbnRvcnkgQ29tbWFuZAAcAAAASW52ZW50b3J5IGFuZCBB
Y2Nlc3MgUmVwb3J0AAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAABAAAAHgAAABAAAABE
ZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPJwAAABQAAABfwJHj5ZYA
AA8A9AMDAKQAS2F2aXRoYSBLcmlzaG5hCAAAAEsAYQB2AGkAdABoAGEAIABLAHIAaQBzAGgAbgBh
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//
/////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

------_=_NextPart_001_01C57A56.D104D1E2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

------_=_NextPart_001_01C57A56.D104D1E2--




From rfid-bounces@lists.ietf.org Sun Jun 26 21:35:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DmiX0-0001jV-DS; Sun, 26 Jun 2005 21:35:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DmiWz-0001jQ-13
	for rfid@megatron.ietf.org; Sun, 26 Jun 2005 21:35:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02920
	for <rfid@ietf.org>; Sun, 26 Jun 2005 21:35:22 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmiw2-0003yH-5A
	for rfid@ietf.org; Sun, 26 Jun 2005 22:01:18 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] RE: draft-krishna-slrrp-02: Repeated Inventory Operations
Date: Sun, 26 Jun 2005 21:34:58 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16EBFF2D6@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] RE: draft-krishna-slrrp-02: Repeated Inventory Operations
Thread-Index: AcV5AR7p+Pu6qUM5T6KbWiZrrVy9+wBtC2zO
From: "P. Krishna" <pkrishna@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 142a000676f5977e1797396caab8b611
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0952251514=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0952251514==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57AB8.6DA10B07"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57AB8.6DA10B07
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Rob,


Access commands _dont_ result in instantaneous RF commands generated by =
the reader. Any access-related RF command is generated only =
post-inventory.=20

=20

Each access command from the RNC create access-specs at the reader. Each =
access-spec defines the follow-up access operation on the inventoried =
tags if they match the tag-spec. A parallel that I can draw to the =
access-specs is access-control lists (ACL) in a router. Basically, a ACL =
defines a set of operations/actions to be performed on a packet if the =
filter-spec (defined as a ternary pattern, starting offset) matches the =
packet contents. Packets as they arrive at the router are looked up, and =
if they match a filter-spec, the corresponding operation/action is =
performed on the packet.


Likewise, a reader performs inventory operation based on inventory =
parameters defined in the inventory command (this step is loosely =
equivalent to a packet arrival and lookup at the router). Inventory =
operation results in tags received by the reader on the air-side. If a =
tag matches one of the tag-spec, a followup access operation is =
performed. Examples of followup access operations include write, kill, =
lock, read user memory etc.

> If I issue an Inventory command, does it execute the previous access =
commands? =20

=20

Just want to get the terminology correct - the reader is not executing =
an access command - instead, it is checking the access-specs.

=20

Yes, the access-specs are checked to see if the tag that was inventoried =
needs any further access operations to be performed.

If there is a need for access operation to be performed, then the =
corresponding air-protocol access operation is performed by the reader =
on that tag.

=20

> If I then issue another inventory command

> does it re-execute the same access commands?  If so, I don't see how =
you clear the list of access commands.

=20

Yes, the access-specs are looked up for subsequent inventory rounds. A =
STOP_ACCESS command deletes the access spec at the reader. Once the =
access-spec is deleted, that <tag-spec, op-spec> related operations are =
no longer performed by the reader.

=20

=20

> I assume that 3.4.7 STOP_INVENTORY is used to terminate an inventory =
that's operating for an extended period on possibly=20

> many tag operations defined by multiple access commands?

=20

Yes STOP_INVENTORY terminates the inventory operation.

=20

Just to clarify, inventory operation is _not_ defined by access =
commands. Inventory operation is defined and started by the Inventory =
command. If there were access-specs defined, then there might have been =
access operations on tags that match the access-specs.=20

=20

/Krishna

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20


------_=_NextPart_001_01C57AB8.6DA10B07
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<html                                                                    =
                                                                      >=0A=
=0A=
<head>=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
<style>=0A=
<!--=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{=0A=
	margin:0in;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman";}=0A=
a:link, span.MsoHyperlink=0A=
	{color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{color:purple;=0A=
	text-decoration:underline;}=0A=
span.EmailStyle17=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle19=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle20=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.SpellE=0A=
	{}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</style>=0A=
=0A=
</head>=0A=
=0A=
<body vlink=3D"purple" link=3D"blue" lang=3D"EN-US" >=0A=
<DIV id=3DidOWAReplyText9594 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi =
Rob,<BR></SPAN></FONT></DIV>=0A=
<DIV dir=3Dltr>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Access commands _dont_ =
result in =0A=
instantaneous RF commands generated by the reader. Any access-related RF =
command =0A=
is generated only post-inventory. </SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Each access command from =
the RNC =0A=
create access-specs at the reader. </SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Each access-spec defines =
the =0A=
follow-up access operation on the inventoried tags if they match the =0A=
tag-spec.&nbsp;A parallel that I can draw to the access-specs&nbsp;is =0A=
access-control lists (ACL)&nbsp;in a router. Basically, a ACL defines a =
set of =0A=
operations/actions to be performed on a packet if the filter-spec =
(defined as a =0A=
ternary pattern, starting offset) matches the packet contents. Packets =
as they =0A=
arrive at the router are looked up, and if they match a filter-spec, the =0A=
corresponding operation/action is performed on the =0A=
packet.</SPAN></FONT></P><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT></DIV><FONT =
face=3DArial =0A=
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">=0A=
<DIV dir=3Dltr><BR>Likewise, a reader performs inventory operation based =
on =0A=
inventory parameters defined in the inventory command (this step is =
loosely =0A=
equivalent to a packet arrival and lookup at the router). Inventory =
operation =0A=
results in tags received by the reader on the air-side. If a tag matches =
one of =0A=
the tag-spec, a followup access operation </SPAN></FONT>is performed. =
Examples =0A=
of followup access operations include write, kill, lock, read user =
memory =0A=
etc.</DIV>=0A=
<DIV dir=3Dltr><BR><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&gt; If I issue an =
Inventory =0A=
command, does it execute the previous access commands?<SPAN>&nbsp; =0A=
</SPAN></SPAN></FONT></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN></SPAN></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN>Just want to get the =0A=
terminology correct -&nbsp;the reader is&nbsp;not executing an access =
command - =0A=
instead, it is checking the access-specs.</SPAN></SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN></SPAN></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN>Yes, the =
access-specs are =0A=
checked to see if the tag that was inventoried needs any further access =0A=
operations to be performed.</SPAN></SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN>If there is a need =
for access =0A=
operation to be performed, then the corresponding air-protocol access =
operation =0A=
is performed by the reader on that tag.</SPAN></SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><SPAN></SPAN></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN>&gt; </SPAN>If I =
then issue =0A=
another inventory command</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&gt;&nbsp;does it =
re-execute the =0A=
same access commands?<SPAN>&nbsp; </SPAN>If so, I don't see how you =
clear the =0A=
list of access commands.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal>Yes, the access-specs are looked up for subsequent =
inventory =0A=
rounds. A STOP_ACCESS command deletes the access spec at the reader. =
Once the =0A=
access-spec is deleted, that &lt;tag-spec, op-spec&gt; related =
operations are no =0A=
longer performed by the reader.</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&gt; I assume that 3.4.7 =0A=
STOP_INVENTORY is used to terminate an inventory that's operating for an =0A=
extended period on possibly </SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&gt; many tag operations =
defined by =0A=
multiple access commands?</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Yes =
STOP_INVENTORY =0A=
terminates the inventory operation.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Just to =
clarify, =0A=
inventory operation is _not_ defined by access commands. Inventory =
operation is =0A=
defined and started by the Inventory command. If there were access-specs =0A=
defined, then there might have been access operations on tags that match =
the =0A=
access-specs. </SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<DIV>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">/Krishna</SPAN></FONT></P></DIV></DIV></DIV>=0A=
=0A=
</body>=0A=
=0A=
</html>=0A=
=0A=
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>=0A=

------_=_NextPart_001_01C57AB8.6DA10B07--


--===============0952251514==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0952251514==--




From rfid-bounces@lists.ietf.org Sun Jun 26 21:45:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dmih7-0003U9-0N; Sun, 26 Jun 2005 21: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 1Dmih5-0003U4-I6
	for rfid@megatron.ietf.org; Sun, 26 Jun 2005 21:45:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03532
	for <rfid@ietf.org>; Sun, 26 Jun 2005 21:45:49 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmj69-0004Gg-31
	for rfid@ietf.org; Sun, 26 Jun 2005 22:11:45 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] draft-krishna-slrrp-02: Filter vs Target Tag parms
Date: Sun, 26 Jun 2005 21:45:28 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16EBFF2D7@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] draft-krishna-slrrp-02: Filter vs Target Tag parms
Thread-Index: AcV5AS+mKmb53yzARnOFxL7g5kuEugBt00x6
From: "P. Krishna" <pkrishna@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============2077629322=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============2077629322==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57AB9.E531F1A3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57AB9.E531F1A3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Section 3.5.5.1.1.3 defines filter parms associated with the inventory =
command in terms of the Gen2 select command.  This=20
> appears to conflict with 3.5.5.1.2.1 where target tag parms are =
associated with an access command.

=20

Hi Rob,

Hopefully, my previous answers/clarifications on access operation would =
have answered this question.

In case it did not ...

=20

Filter params as part of the inventory command =3D=20

Pre-acquisition filter for air-protocols that has a 'gen2 select-like' =
capability.

OR

Post-acquisition filter for air-protocols that do not have that =
capability.

=20

The main goal of the filter param in the inventory command is to reduce =
the RF traffic (in case of pre-acquisition) or network traffic (in case =
of post-acquisition).

=20

=20

Filter params as part of the inventory command =3D=20

defines the tag-spec for the followup access operation. They are =
potentially independent of the inventory filters.=20

=20

=20

It is the responsibility of the RNC to set these filters properly.=20

=20

/Krishna

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20


------_=_NextPart_001_01C57AB9.E531F1A3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<html                                                                    =
                                                                      >=0A=
=0A=
<head>=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
<style>=0A=
<!--=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{=0A=
	margin:0in;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman";}=0A=
a:link, span.MsoHyperlink=0A=
	{color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{color:purple;=0A=
	text-decoration:underline;}=0A=
span.EmailStyle17=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle19=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle20=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.EmailStyle21=0A=
	{=0A=
	font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none;=0A=
	text-decoration:none;}=0A=
span.SpellE=0A=
	{}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
-->=0A=
</style>=0A=
=0A=
</head>=0A=
=0A=
<body vlink=3D"purple" link=3D"blue" lang=3D"EN-US" >=0A=
<DIV id=3DidOWAReplyText59597 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&gt; Section 3.5.5.1.1.3 =
defines =0A=
filter <SPAN class=3DSpellE>parms</SPAN> associated with the inventory =
command in =0A=
terms of the Gen2 select command.<SPAN>&nbsp; </SPAN>This =
</SPAN></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">&gt; appears to conflict =
with =0A=
3.5.5.1.2.1 where target tag <SPAN class=3DSpellE>parms</SPAN> are =
associated with =0A=
an access command.</SPAN></FONT></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi =0A=
Rob,</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hopefully, my =
previous =0A=
answers/clarifications on access operation would have answered this =0A=
question.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In case it =
did not =0A=
...</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Filter params =
as part =0A=
of the inventory command =3D </SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Pre-acquisition filter =0A=
for air-protocols that has a 'gen2 select-like' =
capability.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">OR</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Post-acquisition filter =0A=
for air-protocols that do not have that capability.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The main goal =
of the =0A=
filter param in the inventory command is to reduce the RF traffic (in =
case of =0A=
pre-acquisition) or network traffic (in case of =0A=
post-acquisition).</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Filter params =
as part =0A=
of the inventory command =3D </SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">defines the =
tag-spec =0A=
for the followup access operation. They are potentially independent of =
the =0A=
inventory filters. </SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It is the =0A=
responsibility of the RNC to set these filters&nbsp;properly. =
</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">/Krishna</SPAN></FONT></P></DIV></DIV>=0A=
=0A=
</body>=0A=
=0A=
</html>=0A=
=0A=
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>=0A=

------_=_NextPart_001_01C57AB9.E531F1A3--


--===============2077629322==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============2077629322==--




From rfid-bounces@lists.ietf.org Mon Jun 27 09:53:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dmu34-0007OR-B3; Mon, 27 Jun 2005 09:53:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmu32-0007OM-9i
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 09:53:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22163
	for <rfid@ietf.org>; Mon, 27 Jun 2005 09:53:13 -0400 (EDT)
Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmuSA-00033O-Tp
	for rfid@ietf.org; Mon, 27 Jun 2005 10:19:16 -0400
Received: from [192.168.1.44] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 27 Jun 2005 09:52:35 -0400
Subject: RE: [Rfid] draft-krishna-slrrp-02: Filter vs Target Tag parms
From: "P. Krishna" <pkrishna@revasystems.com>
To: Rob.Buck@intermec.com
In-Reply-To: <0E03681B885F3B4296B999E34435A16EBFF2D7@ms08.mse3.exchange.ms>
References: <0E03681B885F3B4296B999E34435A16EBFF2D7@ms08.mse3.exchange.ms>
Content-Type: text/plain
Message-Id: <1119880353.2928.9.camel@indus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Mon, 27 Jun 2005 09:52:34 -0400
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jun 2005 13:52:35.0137 (UTC)
	FILETIME=[78D53B10:01C57B1F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: rfid@ietf.org
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

On Sun, 2005-06-26 at 21:45, P. Krishna wrote:
> > Section 3.5.5.1.1.3 defines filter parms associated with the
> inventory command in terms of the Gen2 select command.  This 
> > appears to conflict with 3.5.5.1.2.1 where target tag parms are
> associated with an access command.
> 
>  
> 
> Hi Rob,
> 
> Hopefully, my previous answers/clarifications on access operation
> would have answered this question.
> 
> In case it did not ...
> 
>  
> 
> Filter params as part of the inventory command = 
> 
> Pre-acquisition filter for air-protocols that has a 'gen2 select-like'
> capability.
> 
> OR
> 
> Post-acquisition filter for air-protocols that do not have that
> capability.
> 
>  
> 
> The main goal of the filter param in the inventory command is to
> reduce the RF traffic (in case of pre-acquisition) or network traffic
> (in case of post-acquisition).
> 
>  
> 
>  
> 
> Filter params as part of the inventory command = 
                               ^^^^^^^^^

Oops I meant access command!

> 
> defines the tag-spec for the followup access operation. They are
> potentially independent of the inventory filters. 
> 
>  
> 
>  
> 
> It is the responsibility of the RNC to set these filters properly. 
> 
>  
> 
> /Krishna



_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Mon Jun 27 20:08:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn3dy-00029Z-NI; Mon, 27 Jun 2005 20:08:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn3dx-00029L-5r
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 20:08:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14858
	for <rfid@ietf.org>; Mon, 27 Jun 2005 20:07:59 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: from agate.intermec.com ([63.127.92.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn43B-0001pA-PR
	for rfid@ietf.org; Mon, 27 Jun 2005 20:34:06 -0400
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BN0A>; Mon, 27 Jun 2005 19:07:58 -0500
Message-ID: <49E558014BABD711AA980002A5421C99072A21D9@normail.norand.com>
To: rfid@ietf.org
Subject: RE: [Rfid] draft-krishna-slrrp-02: Data "smoothing"
Date: Mon, 27 Jun 2005 19:07:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: d62adab73c3674ddf4d2b0d221683819
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0588872388=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============0588872388==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57B75.705E8F44"

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_01C57B75.705E8F44
Content-Type: text/plain

Krishna,

 

I agree with your comments regarding the need to report tag read counts.  We
provide this capability today and our solutions providers find it useful.

 

3.5.4.5 describes Inventory timing parameters.  I suggest defining a value
(0 or -1, either number of rounds or round size) to indicate continuous,
non-stop reading (until inventory stop command).

 

Our experience is that there's a common use-case for continuous reading,
coupled with periodic reports and "tag seen" counts.

 

I think you need two more features:

 

-          An option to report "tag seen" immediately when seen for the
first time.

-          External triggered reads - i.e., don't read continuously but only
when triggered by a sensor.  This is necessary for European duty-cycle
regulatory requirements.  Otherwise, the interface can be the same: report
tags and counts periodically and optionally report tags immediately when
first seen.

 

Rob

 

   _____  

From: P. Krishna [mailto:pkrishna@revasystems.com] 
Sent: Sunday, June 26, 2005 7:59 AM
To: Rob.Buck@intermec.com; rfid@ietf.org
Subject: RE: [Rfid] draft-krishna-slrrp-02: Data "smoothing"

 

Rob,

We stayed away from defining an elaborate smoothing engine in SLRRP.
Basically, there are 2 knobs we provide to control the traffic rate from the
reader:

(i) the frequency (rate) of the inventory and access reports generated and
transmitted by the reader to the RNC - this is controlled by defining
'triggers' in Section 3.5.6.1. The trigger is a byte wide - different types
of triggers can be defined. We have currently defined only 2 types - one of
them says send the report every inventory round, the other says send the
report every T time units. We are open to defining more types of triggers. 

 

(ii) the frequency of the tag data itself inside the report: this seems to
be the major concern of a RFID reader network.  Just so everybody is on the
same page, I'll just illustrate with a simple example. A reader can see a
tag many times (say 10 times) during an inventory round - a simple
implementation is to have the report the tag 10 times in the report - i.e.,
if the tag data is 100B, then we are consuming 10 * 100B = 1 KB on the wire.
If this happens to each and every tag seen by the reader, then we are
consuming 10x of the bandwidth and there is "no" perceived extra information
conveyed in the duplicate data.

 

There is a class of applications or hosts that is just interested in knowing
a binary information per tag by the reader (i.e., has the reader seen it or
not) - for them, sending 10 instances of each tag is a waste and redundant.
Instead they would like a clean list of N tags 'observed' by the reader.

As you are aware that there is already a application-layer protocol (ALE) in
EPCglobal that provides that interface - unfortunately I cannot go into
those details in this mailing list. ALE provides the right reader interface
to those applications.

 

We dont believe in wasting bandwidth on the network (its obvious from one of
our design points - binary encoding). But, we also believe that there is
'rich' information in knowing how many times a tag was observed by the
reader - this provides information of the quality of the read. An
infrastructure device can do some richer inference from such information
from multiplicity of readers. 

 

We have a 'RFU' (reserved for future use) field in the "Tag Data Parameter"
(section 3.5.6.3) - we intend to use that field to send information like the
"number of times the tag was seen", "the RF frequency at which it was
captured" etc. So, if a tag is seen 10 times, we set the "number of times
the tag was seen" for that tag to 10. This way, we are not sending 10x
traffic, but still are able to convey the rich information up to the
infrastructure device.

 

I hope that helps.

 

/Krishna

 

 

 

 

   _____  

From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Fri 6/24/2005 4:28 PM
To: rfid@ietf.org
Subject: [Rfid] draft-krishna-slrrp-02: Data "smoothing"

Does SLRRP provide a mechanism for "smoothing" RFID data - i.e., eliminating
duplicate reads?  If not, is there no concern about unnecessary network
traffic transmitting a significant amount of redundant data?

 

Rob

 

"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited." 

"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C57B75.705E8F44
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"
 downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.25in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:484516177;
	mso-list-type:hybrid;
	mso-list-template-ids:1011650286 -126447334 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:3;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><st1:place w:st=3D"on"><font size=3D2 color=3Dnavy =
face=3DArial><span
 =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Krishna</span></=
font></st1:place><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with your comments =
regarding the
need to report tag read counts.&nbsp; We provide this capability today =
and our
solutions providers find it useful.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>3.5.4.5 describes Inventory timing
parameters.&nbsp; I suggest defining a value (0 or -1, either number of =
rounds
or round size) to indicate continuous, non-stop reading (until =
inventory stop
command).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Our experience is that =
there&#8217;s a
common use-case for continuous reading, coupled with periodic reports =
and &#8220;tag
seen&#8221; counts.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I think you need two more =
features:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>An option
to report &#8220;tag seen&#8221; immediately when seen for the first =
time.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>External
triggered reads &#8211; i.e., don&#8217;t read continuously but only =
when
triggered by a sensor. &nbsp;This is necessary for European duty-cycle
regulatory requirements.&nbsp; Otherwise, the interface can be the =
same: report
tags and counts periodically and optionally report tags immediately =
when first
seen.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Rob<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> P. =
Krishna
[mailto:pkrishna@revasystems.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Sunday, June 26, =
2005 7:59
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
Rob.Buck@intermec.com;
rfid@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [Rfid]
draft-krishna-slrrp-02: Data =
&quot;smoothing&quot;</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div id=3DidOWAReplyText73018>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:black'>Rob,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We stayed away from defining an elaborate smoothing =
engine
in SLRRP. Basically, there are 2 knobs we provide to control the =
traffic rate
from the reader:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>(i) the frequency (rate)&nbsp;of the inventory and =
access
reports generated and transmitted by the reader to the RNC - this is =
controlled
by defining 'triggers' in Section 3.5.6.1. The trigger is a byte wide -
different types of triggers can be defined. We have currently defined =
only 2
types - one of them says send the report every inventory round, the =
other says
send the report every T time units. We are open to defining more types =
of
triggers. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>(ii) the frequency of the tag data itself inside the =
report:
this&nbsp;seems to be&nbsp;the major concern of a RFID reader =
network.&nbsp;
Just so everybody is on the same page, I'll just illustrate with a =
simple
example. A reader can see a tag many times (say 10 times) during an
inventory&nbsp;round - a simple implementation is to have the report =
the tag 10
times in the report - i.e., if the tag data is 100B, then we are =
consuming 10 *
100B =3D 1 KB on the wire. If this happens to each and every tag seen =
by the
reader, then we are consuming 10x of the bandwidth and there is =
&quot;no&quot;
perceived extra information conveyed in the duplicate =
data.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>There is a class of&nbsp;applications or&nbsp;hosts
that&nbsp;is just interested in knowing a binary information per =
tag&nbsp;by
the reader (i.e., has the reader seen it or not) - for them, sending 10
instances of each tag is a waste and redundant. Instead they would like =
a clean
list of N tags 'observed' by the reader.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As you are aware that there is already a =
application-layer
protocol (ALE) in EPCglobal that&nbsp;provides that interface - =
unfortunately I
cannot go into those details in this mailing list.&nbsp;ALE provides =
the right
reader interface to those applications.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We dont believe in wasting bandwidth on the network =
(its
obvious from one of our design points&nbsp;- binary encoding). But, we =
also
believe that there is 'rich' information in knowing how many times a =
tag was
observed by the reader - this provides information of the quality of =
the read.
An infrastructure device can do some richer inference from such =
information
from multiplicity of readers. </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We have a 'RFU' (reserved for future use) field in =
the
&quot;Tag Data Parameter&quot; (section 3.5.6.3) - we intend to use =
that field
to send information like the &quot;number of times the tag was =
seen&quot;,
&quot;the RF frequency at which it was captured&quot; etc. So, if a tag =
is seen
10 times, we&nbsp;set the &quot;number of times the tag was seen&quot; =
for that
tag to 10. This way, we are not sending 10x traffic, but still are able =
to
convey the rich information up to the infrastructure =
device.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I hope that helps.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>/<st1:place =
w:st=3D"on">Krishna</st1:place></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</sp=
an></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> =
rfid-bounces@lists.ietf.org
on behalf of Rob.Buck@intermec.com<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Fri 6/24/2005 4:28 =
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> rfid@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Rfid]
draft-krishna-slrrp-02: Data =
&quot;smoothing&quot;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Does SLRRP provide a mechanism for
&quot;smoothing&quot; RFID data - i.e., eliminating duplicate reads? =
&nbsp;If
not, is there no concern about unnecessary network traffic transmitting =
a
significant amount of redundant data?</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Rob</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C57B75.705E8F44--


--===============0588872388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0588872388==--




From rfid-bounces@lists.ietf.org Mon Jun 27 20:20:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn3pi-00051Y-A5; Mon, 27 Jun 2005 20:20:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn3pg-00050y-Pt
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 20:20:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15835
	for <rfid@ietf.org>; Mon, 27 Jun 2005 20:20:06 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: from agate.intermec.com ([63.127.92.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn4Ev-00034H-7P
	for rfid@ietf.org; Mon, 27 Jun 2005 20:46:14 -0400
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BN0C>; Mon, 27 Jun 2005 19:20:14 -0500
Message-ID: <49E558014BABD711AA980002A5421C99072A21DF@normail.norand.com>
To: rfid@ietf.org
Subject: [Rfid] draft-krishna-slrrp-02: 3.5.5.1.1.4.  EPC C1G2 Protocol In
	ventory Command Parameters
Date: Mon, 27 Jun 2005 19:20:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: 
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


Regarding: 3.5.5.1.1.4.  EPC C1G2 Protocol Inventory Command Parameters

I see you have the "repeat forever" covered here.  In that case, should the
Inventory Timing Parameter should be optional?

Singulation and RF parameters are optional.  If omitted what values are used
-- the last values set?  Should these values be settable with
SET_READER_CONFIG to establish default values that persist after a reboot?

Rob
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Mon Jun 27 21:21:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn4n8-0001T0-5z; Mon, 27 Jun 2005 21:21:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn4n6-0001Sv-WA
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 21:21:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20158
	for <rfid@ietf.org>; Mon, 27 Jun 2005 21:21:30 -0400 (EDT)
Received: from web308.biz.mail.mud.yahoo.com ([68.142.199.184])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dn5CJ-0000oe-Uz
	for rfid@ietf.org; Mon, 27 Jun 2005 21:47:39 -0400
Message-ID: <20050628012114.71084.qmail@web308.biz.mail.mud.yahoo.com>
Received: from [209.6.248.193] by web308.biz.mail.mud.yahoo.com via HTTP;
	Mon, 27 Jun 2005 18:21:14 PDT
Date: Mon, 27 Jun 2005 18:21:14 -0700 (PDT)
From: Bud Biswas <bbiswas@polarisnetworks.net>
To: rfid@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: [Rfid] Gen-1 and Gen-2 Support in SLRRP
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bbiswas@polarisnetworks.net
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

Hello Krishna:

In the RFC you state that the RNC will support both Gen-1 and Gen-2
readers. When we send the GET_READER_INFO command to reader, don't we
need to know the Gen type of the RFC ? Many subsequent
command/responses are tied to C1G2 readers only. We do not need those
when we are talking to a C0/1G1 reader.

For that matter, should not not have the other classes of tags as well
?

thanks

Bud
Polaris Networks
RFID Test Tools Group



_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Mon Jun 27 22:20:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn5hw-00056f-GZ; Mon, 27 Jun 2005 22:20:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn5hu-00056a-Cg
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 22:20:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24100
	for <rfid@ietf.org>; Mon, 27 Jun 2005 22:20:11 -0400 (EDT)
Received: from web311.biz.mail.mud.yahoo.com ([68.142.199.187])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dn679-0006NN-NW
	for rfid@ietf.org; Mon, 27 Jun 2005 22:46:21 -0400
Message-ID: <20050628022004.68052.qmail@web311.biz.mail.mud.yahoo.com>
Received: from [209.6.248.193] by web311.biz.mail.mud.yahoo.com via HTTP;
	Mon, 27 Jun 2005 19:20:03 PDT
Date: Mon, 27 Jun 2005 19:20:03 -0700 (PDT)
From: Bud Biswas <bbiswas@polarisnetworks.net>
To: rfid@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: 
Subject: [Rfid] SLRRP draft 02: Support of multiple protocols by a single
	antenna ?
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bbiswas@polarisnetworks.net
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

Krishna:

In section 3.4.5, we are assuming that a single antenna (as designated
by the antenna id field) can read multiple air protocol tags. This
happens we set a value of 7 in the air protocol field implying that we
want to read tags of types, C0G1, C1G1 and C1G2. Is this the intention
?

Also, it is possible that RNC does not know the type of tags a reader
can read. The reader is capable of only some types. Then the reader can
send a response of what types it is supporting. Is it something
desirable ?may be the reader has sent that info to RNC with the
GET_READER_INFO_RESPONSE.

Thanks.

Bud

Polaris Networks
RFID Test Tools Group


B. Biswas
President and CEO, Polaris Networks
781-698-9049
bbiswas@polarisnetworks.net

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Mon Jun 27 22:27:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn5p5-0006XL-TN; Mon, 27 Jun 2005 22:27:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn5p4-0006W0-AH
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 22:27:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24505
	for <rfid@ietf.org>; Mon, 27 Jun 2005 22:27:33 -0400 (EDT)
Received: from e5.ny.us.ibm.com ([32.97.182.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn6EH-00079X-SI
	for rfid@ietf.org; Mon, 27 Jun 2005 22:53:43 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5S2RLdL004574
	for <rfid@ietf.org>; Mon, 27 Jun 2005 22:27:21 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id
	j5S2RLB1208822 for <rfid@ietf.org>; Mon, 27 Jun 2005 22:27:21 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5S2RL2v027763
	for <rfid@ietf.org>; Mon, 27 Jun 2005 22:27:21 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-65-228-31.mts.ibm.com
	[9.65.228.31])
	by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5S2RKjG027580
	for <rfid@ietf.org>; Mon, 27 Jun 2005 22:27:21 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j5S2PJYQ006066
	for <rfid@ietf.org>; Mon, 27 Jun 2005 22:25:23 -0400
Message-Id: <200506280225.j5S2PJYQ006066@cichlid.raleigh.ibm.com>
To: rfid@ietf.org
Date: Mon, 27 Jun 2005 22:25:19 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: 
Subject: [Rfid] status of the SLRRP effort
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

Can someone tell me the status of this effort within the IETF?

There has been relatively little traffic on the list since the
Minneapolis BOF. I also don't recall discussion of a revised charter,
or submission of one to the IESG for formal consideration. Finally,
with the Paris meeting coming up, there has been no followup
concerning whether a meeting is planned and/or what its focus would
be.

Can I assume that the conclusion of the Minneapolis BOF is that no WG
will be formed at this time?

Thomas

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Mon Jun 27 22:57:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn6HU-0003cy-GN; Mon, 27 Jun 2005 22:57:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6HT-0003ct-9q
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 22:56:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26758
	for <rfid@ietf.org>; Mon, 27 Jun 2005 22:56:56 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn6gi-0001C3-4O
	for rfid@ietf.org; Mon, 27 Jun 2005 23:23:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] draft-krishna-slrrp-02: 3.5.5.1.1.4. EPC C1G2 Protocol
	Inventory Command Parameters
Date: Mon, 27 Jun 2005 22:56:38 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16EBFF2DC@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] draft-krishna-slrrp-02: 3.5.5.1.1.4. EPC C1G2 Protocol
	Inventory Command Parameters
Thread-Index: AcV7d0hnm2hsZO0AQxCRfOpnge99wgAFP29X
From: "P. Krishna" <pkrishna@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0554964762=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0554964762==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57B8D.012243DB"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57B8D.012243DB
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

________________________________

From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Mon 6/27/2005 8:20 PM
To: rfid@ietf.org
Subject: [Rfid] draft-krishna-slrrp-02: 3.5.5.1.1.4. EPC C1G2 Protocol =
Inventory Command Parameters

> Regarding: 3.5.5.1.1.4.  EPC C1G2 Protocol Inventory Command =
Parameters

> I see you have the "repeat forever" covered here.  In that case, =
should the
> Inventory Timing Parameter should be optional?

yes you are correct, it is covered here. For the "repeat forever", the =
Inventory timing parameter specifies the start-time for the inventory =
operation, and the round-size.

> Singulation and RF parameters are optional.  If omitted what values =
are used
> -- the last values set?  Should these values be settable with
> SET_READER_CONFIG to establish default values that persist after a =
reboot?


These values are optional and uses the last values set during an earlier =
inventory operation, or, as you mention set with SET_READER_CONFIG.  All =
the parameters are settable using SET_READER_CONFIG. This provides the =
flexibility of treating these parameters as a "configuration" (if set =
using SET_READER_CONFIG) and will persist till changed, or as a =
"real-time control" (if set/changed with each inventory command).

=20

/Krishna


------_=_NextPart_001_01C57B8D.012243DB
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">=0A=
<TITLE>[Rfid] draft-krishna-slrrp-02: 3.5.5.1.1.4.  EPC C1G2 Protocol =
Inventory Command Parameters</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText26947 dir=3Dltr>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
rfid-bounces@lists.ietf.org =0A=
on behalf of Rob.Buck@intermec.com<BR><B>Sent:</B> Mon 6/27/2005 8:20 =0A=
PM<BR><B>To:</B> rfid@ietf.org<BR><B>Subject:</B> [Rfid] =
draft-krishna-slrrp-02: =0A=
3.5.5.1.1.4. EPC C1G2 Protocol Inventory Command =
Parameters<BR></FONT><BR><FONT =0A=
size=3D2>&gt; Regarding: 3.5.5.1.1.4.&nbsp; EPC C1G2 Protocol Inventory =
Command =0A=
Parameters<BR><BR>&gt; I see you have the "repeat forever" covered =
here.&nbsp; =0A=
In that case, should the<BR></FONT><FONT size=3D2>&gt; Inventory Timing =
Parameter =0A=
should be optional?<BR></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>yes you are correct, it is covered here. =
</FONT><FONT =0A=
size=3D2>For the "repeat forever", the Inventory timing parameter =
specifies the =0A=
start-time </FONT><FONT size=3D2>for the inventory operation, and the =0A=
round-size.</FONT></DIV></DIV>=0A=
<DIV><FONT size=3D2>=0A=
<P><BR>&gt; Singulation and RF parameters are optional.&nbsp; If omitted =
what =0A=
values are used<BR>&gt; -- the last values set?&nbsp; Should these =
values be =0A=
settable with<BR>&gt; SET_READER_CONFIG to establish default values that =
persist =0A=
after a reboot?<BR></P>=0A=
<P>These values are optional and uses the last values set during an =
earlier =0A=
inventory operation, or, as you mention set with =
SET_READER_CONFIG.&nbsp; All =0A=
the parameters are settable using SET_READER_CONFIG. This provides the =0A=
flexibility of treating these parameters as a "configuration" (if set =
using =0A=
SET_READER_CONFIG) and will persist till changed, or as a "real-time =
control" =0A=
(if set/changed with each inventory command).</P>=0A=
<P>&nbsp;</P>=0A=
<P>/Krishna</P></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C57B8D.012243DB--


--===============0554964762==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0554964762==--




From rfid-bounces@lists.ietf.org Mon Jun 27 23:34:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn6ro-0001sz-1C; Mon, 27 Jun 2005 23:34:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6rm-0001st-SP
	for rfid@megatron.ietf.org; Mon, 27 Jun 2005 23:34:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29547
	for <rfid@ietf.org>; Mon, 27 Jun 2005 23:34:27 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn7H3-0004Kd-IE
	for rfid@ietf.org; Tue, 28 Jun 2005 00:00:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] draft-krishna-slrrp-02: Data "smoothing"
Date: Mon, 27 Jun 2005 23:34:21 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16EBFF2DD@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] draft-krishna-slrrp-02: Data "smoothing"
Thread-Index: AcV7dYbKUVRftxKXQKeawIb5AZd7FQAF371y
From: "P. Krishna" <pkrishna@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 64b72a8e61417554b4b727cb14e7034d
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0879946281=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0879946281==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57B92.4583DD84"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57B92.4583DD84
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Rob,
=20
> I agree with your comments regarding the need to report tag read =
counts.  We provide this capability today and our solutions providers=20

> find it useful.

=20

Thats great.

=20

> 3.5.4.5 describes Inventory timing parameters.  I suggest defining a =
value (0 or -1, either number of rounds or round size) to indicate=20

> continuous, non-stop reading (until inventory stop command).

=20

Looks like you figured it out in your next email !!

=20

> Our experience is that there's a common use-case for continuous =
reading, coupled with periodic reports and "tag seen" counts.

=20

Its good to know that we've covered the common use-case using slrrp =
while still being able to provide deeper controls when necessary.

=20

=20

> I think you need two more features:

=20

Excellent suggestions.=20

=20

> -          An option to report "tag seen" immediately when seen for =
the first time.

=20

Regarding "tag seen", do you see value in reporting as soon any tag is =
seen for the first  time? Or do you want to go to the extent of =
specifying a particular filter-pattern and only tags matching the =
pattern triggers a report? As I mentioned in an earlier email yesterday, =
we've just defined couple of triggers for reports and both are =
time-based.  The trigger field is a byte wide - we can define a lot more =
triggers. Its great you point this particular requirement out. What =
other triggers do you think we should support ? Just to be in sync, we =
are just talking about reporting triggers - i.e., when to send an =
inventory/access report back.

=20

Following are the triggers:

- every inventory round

- every T time units

- as per your suggestion, upon seeing a tag for the first time
--> anything else?

=20

Your second suggestion is external triggered reads ...=20

=20

> -          External triggered reads - i.e., don't read continuously =
but only when triggered by a sensor.  This is necessary for European=20

> duty-cycle regulatory requirements.  Otherwise, the interface can be =
the same: report tags and counts periodically and optionally=20

> report tags immediately when first seen.

=20

Currently what we have defined is for the triggers to go back to the RNC =
via the Reader Status Report. This way if the RNC has to turn around and =
generate the inventory commands, it can do that - and the RNC remains =
cognizant of the RF usage in the network.

The other option is to extend the Inventory Timing operation parameter - =
in terms of start time, we have 2 options, a) to start now, or b) to =
start @ a specific time. We may want to extend this to "start upon a =
defined external trigger". The duration of the round & # of rounds are =
already defined in the timing operation parameter.

=20

Let me know if this works for you.

=20

Thank you for the input - looking forward to more suggestions from you.

=20

Regards,

Krishna

=20

=20

=20

=20

=20

=20

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20


------_=_NextPart_001_01C57B92.4583DD84
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<html                                                                    =
                                                                         =
                                                                         =
                   >=0A=
=0A=
<head>=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
<style>=0A=
<!--=0A=
                       =0A=
 font-face=0A=
	{font-family:Wingdings;}=0A=
font-face=0A=
	{font-family:Tahoma;}=0A=
                        =0A=
 p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
	{margin:0in;=0A=
	margin-bottom:.0001pt;=0A=
	font-size:12.0pt;=0A=
	font-family:"Times New Roman";}=0A=
a:link, span.MsoHyperlink=0A=
	{color:blue;=0A=
	text-decoration:underline;}=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
	{color:purple;=0A=
	text-decoration:underline;}=0A=
span.emailstyle17=0A=
	{font-family:Arial;=0A=
	color:blue;=0A=
	font-weight:normal;=0A=
	font-style:normal;=0A=
	text-decoration:none none;}=0A=
span.EmailStyle18=0A=
	{=0A=
	font-family:Arial;=0A=
	color:navy;}=0A=
=0A=
div.Section1=0A=
	{page:Section1;}=0A=
                       =0A=
 =0A=
=0A=
ol=0A=
	{margin-bottom:0in;}=0A=
ul=0A=
	{margin-bottom:0in;}=0A=
-->=0A=
</style>=0A=
=0A=
</head>=0A=
=0A=
<body vlink=3D"purple" link=3D"blue" lang=3D"EN-US">=0A=
<DIV id=3DidOWAReplyText73050 dir=3Dltr>=0A=
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT></P>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi =0A=
Rob,</SPAN></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; I agree =
with your =0A=
comments regarding the need to report tag read counts.&nbsp; We provide =
this =0A=
capability today and our solutions providers </SPAN></FONT></DIV></DIV>=0A=
<DIV>=0A=
<DIV class=3DSection1>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; find it =0A=
useful.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thats =0A=
great.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; 3.5.4.5 =
describes =0A=
Inventory timing parameters.&nbsp; I suggest defining a value (0 or -1, =
either =0A=
number of rounds or round size) to indicate </SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; =
continuous, =0A=
non-stop reading (until inventory stop command).</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Looks like =
you figured =0A=
it out in your next email !!</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; Our =
experience is =0A=
that there&#8217;s a common use-case for continuous reading, coupled =
with periodic =0A=
reports and &#8220;tag seen&#8221; counts.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Its good to =
know that =0A=
we've covered the common use-case using slrrp while still being able to =
provide =0A=
deeper controls when necessary.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; I think =
you need =0A=
two more features:</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Excellent =
suggestions. =0A=
</SPAN></SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN>&gt; =
-<FONT =0A=
face=3D"Times New Roman" size=3D1><SPAN =0A=
style=3D"FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; =
FONT-STYLE: normal; FONT-VARIANT: normal" =0A=
??>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
</SPAN></FONT></SPAN></SPAN></FONT><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">An option to =
report =0A=
&#8220;tag seen&#8221; immediately when seen for the first =
time.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regarding =
"tag seen", =0A=
do you see value in reporting as soon any tag is seen for the =
first&nbsp; time? =0A=
Or do you want to go to the extent of specifying a particular =
filter-pattern and =0A=
only tags matching the pattern triggers a report? As I mentioned in an =
earlier =0A=
email yesterday, we've just defined couple of triggers for reports and =
both are =0A=
time-based.&nbsp; The trigger field is a byte wide - we can define a lot =
more =0A=
triggers. Its great you point this particular requirement out. What =
other =0A=
triggers do you think we should support ? Just to be in sync, we are =
just =0A=
talking about reporting triggers - i.e., when to send an =
inventory/access report =0A=
back.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Following are =
the =0A=
triggers:</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">- every =
inventory =0A=
round</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">- every T =
time =0A=
units</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">- as per your =0A=
suggestion, upon seeing a tag for the first time<BR>--&gt; anything =0A=
else?</SPAN></FONT></P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Your second =
suggestion =0A=
is external triggered reads ... </P></SPAN></FONT>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN>&gt; =
-<FONT =0A=
face=3D"Times New Roman" size=3D1><SPAN =0A=
style=3D"FONT-WEIGHT: normal; FONT-SIZE: 7pt; LINE-HEIGHT: normal; =
FONT-STYLE: normal; FONT-VARIANT: normal" =0A=
??>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
</SPAN></FONT></SPAN></SPAN></FONT><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">External =
triggered =0A=
reads &#8211; i.e., don&#8217;t read continuously but only when =
triggered by a sensor. =0A=
&nbsp;This is necessary for European </SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; =
duty-cycle =0A=
regulatory requirements.&nbsp; Otherwise, the interface can be the same: =
report =0A=
tags and counts periodically and optionally </SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&gt; report =
tags =0A=
immediately when first seen.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Currently =
what we have =0A=
defined is for the triggers to go back to the RNC via the Reader Status =
Report. =0A=
This way if the RNC has to turn around and generate the inventory =
commands, it =0A=
can do that - and the RNC&nbsp;remains cognizant of the RF usage in the =0A=
network.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The other =
option is to =0A=
extend the Inventory Timing operation parameter - in terms of start =
time, we =0A=
have 2 options, a) to start now, or b) to start @ a specific time. We =
may want =0A=
to extend this to "start upon a defined external trigger". The duration =
of the =0A=
round &amp; # of rounds are already defined in the timing operation =0A=
parameter.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Let me know =
if this =0A=
works for you.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thank you for =
the input =0A=
- looking forward to more suggestions from you.</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Krishna</SPAN></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: =
-0.25in"><FONT =0A=
face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></SPAN></FONT>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =0A=
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>=0A=
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =0A=
style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV></DIV>=0A=
=0A=
</body>=0A=
=0A=
</html>=0A=
<P><FONT SIZE=3D"2" FACE=3D"Arial">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>=0A=
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>=0A=

------_=_NextPart_001_01C57B92.4583DD84--


--===============0879946281==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0879946281==--




From rfid-bounces@lists.ietf.org Tue Jun 28 02:40:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn9m4-0004ME-Be; Tue, 28 Jun 2005 02:40:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9m2-0004M2-Nu
	for rfid@megatron.ietf.org; Tue, 28 Jun 2005 02:40:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04128
	for <rfid@ietf.org>; Tue, 28 Jun 2005 02:40:45 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnABL-0000Aw-5c
	for rfid@ietf.org; Tue, 28 Jun 2005 03:06:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] draft-krishna-slrrp-02: no serial device support?
Date: Tue, 28 Jun 2005 02:38:34 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16E3733C9@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] draft-krishna-slrrp-02: no serial device support?
Thread-Index: AcV4/qMaUb+zujaFSMGW/Wgj1kYkPwCrV7XI
From: "Scott Barvick" <sbarvick@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0462981585=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0462981585==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57BAC.4A36D813"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57BAC.4A36D813
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Rob,

The simple answer is that specifying a serial line transport for SLRRP =
or attempting to provide for scalable operations and management for =
serial-connected RFID devices is not in the current working group =
charter proposal.  The reason for this is that the biggest benefit going =
forward for standardization and the resulting scalability and =
interoperability will occur for the huge number of ethernet/802.11 IP =
connected readers forecast to be deployed in the coming years. =20

However, there are no specific TCP/IP parameters carried in the SLRRP =
protocol and it is intended to be efficient in terms of network =
bandwidth and reader resource requirements.  Therefore, it seems =
possible that SLRRP could be run over a serial line without much effort =
which could help RNC implementations that have a requirement to talk to =
both types of devices.  It also seems that specifying other transports =
for the base SLRRP protocol might be an area for =
cross-development/liaison with other organizations that have this =
requirement.=20

Scott


-----Original Message-----
From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Fri 6/24/2005 4:50 PM
To: rfid@ietf.org
Subject: [Rfid] draft-krishna-slrrp-02: no serial device support?
=20
SLRRP is a network protocol.  Is it safe to say that SLRRP does not =
apply to low-end, serial readers?  Was there any consideration given to =
non-network readers?

=20

Rob

=20

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20



------_=_NextPart_001_01C57BAC.4A36D813
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>RE: [Rfid] draft-krishna-slrrp-02: no serial device =
support?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Rob,<BR>
<BR>
The simple answer is that specifying a serial line transport for SLRRP =
or attempting to provide for scalable operations and management for =
serial-connected RFID devices is not in the current working group =
charter proposal.&nbsp; The reason for this is that the biggest benefit =
going forward for standardization and the resulting scalability and =
interoperability will occur for the huge number of ethernet/802.11 IP =
connected readers forecast to be deployed in the coming years.&nbsp;<BR>
<BR>
However, there are no specific TCP/IP parameters carried in the SLRRP =
protocol and it is intended to be efficient in terms of network =
bandwidth and reader resource requirements.&nbsp; Therefore, it seems =
possible that SLRRP could be run over a serial line without much effort =
which could help RNC implementations that have a requirement to talk to =
both types of devices.&nbsp; It also seems that specifying other =
transports for the base SLRRP protocol might be an area for =
cross-development/liaison with other organizations that have this =
requirement.<BR>
<BR>
Scott<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com<BR>
Sent: Fri 6/24/2005 4:50 PM<BR>
To: rfid@ietf.org<BR>
Subject: [Rfid] draft-krishna-slrrp-02: no serial device support?<BR>
<BR>
SLRRP is a network protocol.&nbsp; Is it safe to say that SLRRP does not =
apply to low-end, serial readers?&nbsp; Was there any consideration =
given to non-network readers?<BR>
<BR>
<BR>
<BR>
Rob<BR>
<BR>
<BR>
<BR>
&quot;This message is intended only for the named recipient. If you are =
not the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited.&quot;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57BAC.4A36D813--


--===============0462981585==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0462981585==--




From rfid-bounces@lists.ietf.org Tue Jun 28 02:45:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dn9qT-0005fg-4j; Tue, 28 Jun 2005 02:45:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9qQ-0005fE-Cv
	for rfid@megatron.ietf.org; Tue, 28 Jun 2005 02:45:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04685
	for <rfid@ietf.org>; Tue, 28 Jun 2005 02:45:17 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnAFi-0000mB-5c
	for rfid@ietf.org; Tue, 28 Jun 2005 03:11:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] RE: draft-krishna-slrrp-02: SLRRP RNC API?
Date: Tue, 28 Jun 2005 02:40:46 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16E3733CA@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] RE: draft-krishna-slrrp-02: SLRRP RNC API?
Thread-Index: AcV4/yFHh0PK+2tYRv2jSDQiD6MUkACrS9rl
From: "Scott Barvick" <sbarvick@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============1989229684=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1989229684==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57BAC.EC59EE70"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57BAC.EC59EE70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Rob,

I don't see the RNC API as something that gets standardized, at least =
not by this working group.  The RNC is a logical entity that we needed =
to give a name in the document so that we could refer to the entity at =
the "other end" of the SLRRP connection - the end that is not the reader =
interrogating tags.  SLRRP is just a point to point network interface =
between an RNC and a single reader.  It may be one reader supporting a =
single application or it may be in an array of hundreds of readers fully =
instrumenting a facility.   In these extremes or somewhere in the =
middle, the function of the RNC will be very different, from a thin shim =
that just sends SLRRP commands directly from a specific application to a =
fully functioning reader array controller that manages many facets of =
the reader array.  It also may run on many different types of devices.  =
We've heard examples of RNCs that would be application software, readers =
with lots of CPU and memory, dedicated control devices, and even routers =
with server blades.   All of this leads me to the conclusion that an RNC =
function is best left for specific products that use SLRRP to talk to =
readers and that no API to this function is possible to standardize.

Scott


-----Original Message-----
From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Fri 6/24/2005 4:55 PM
To: rfid@ietf.org
Subject: [Rfid] RE: draft-krishna-slrrp-02: SLRRP RNC API?
=20
Is there any plan to standardize an API for the RNC side of SLRRP?

=20

Rob Buck

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20



------_=_NextPart_001_01C57BAC.EC59EE70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>RE: [Rfid] RE: draft-krishna-slrrp-02: SLRRP RNC API?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Rob,<BR>
<BR>
I don't see the RNC API as something that gets standardized, at least =
not by this working group.&nbsp; The RNC is a logical entity that we =
needed to give a name in the document so that we could refer to the =
entity at the &quot;other end&quot; of the SLRRP connection - the end =
that is not the reader interrogating tags.&nbsp; SLRRP is just a point =
to point network interface between an RNC and a single reader.&nbsp; It =
may be one reader supporting a single application or it may be in an =
array of hundreds of readers fully instrumenting a facility.&nbsp;&nbsp; =
In these extremes or somewhere in the middle, the function of the RNC =
will be very different, from a thin shim that just sends SLRRP commands =
directly from a specific application to a fully functioning reader array =
controller that manages many facets of the reader array.&nbsp; It also =
may run on many different types of devices.&nbsp; We've heard examples =
of RNCs that would be application software, readers with lots of CPU and =
memory, dedicated control devices, and even routers with server =
blades.&nbsp;&nbsp; All of this leads me to the conclusion that an RNC =
function is best left for specific products that use SLRRP to talk to =
readers and that no API to this function is possible to standardize.<BR>
<BR>
Scott<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com<BR>
Sent: Fri 6/24/2005 4:55 PM<BR>
To: rfid@ietf.org<BR>
Subject: [Rfid] RE: draft-krishna-slrrp-02: SLRRP RNC API?<BR>
<BR>
Is there any plan to standardize an API for the RNC side of SLRRP?<BR>
<BR>
<BR>
<BR>
Rob Buck<BR>
<BR>
&quot;This message is intended only for the named recipient. If you are =
not the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited.&quot;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57BAC.EC59EE70--


--===============1989229684==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1989229684==--




From rfid-bounces@lists.ietf.org Tue Jun 28 10:30:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnH6z-0001l2-9y; Tue, 28 Jun 2005 10:30:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnH6x-0001kx-NT
	for rfid@megatron.ietf.org; Tue, 28 Jun 2005 10:30:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14637
	for <rfid@ietf.org>; Tue, 28 Jun 2005 10:30:49 -0400 (EDT)
Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnHWJ-0001BZ-G5
	for rfid@ietf.org; Tue, 28 Jun 2005 10:57:04 -0400
Received: from [192.168.1.44] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 28 Jun 2005 10:30:45 -0400
Subject: Re: [Rfid] Gen-1 and Gen-2 Support in SLRRP
From: "P. Krishna" <pkrishna@revasystems.com>
To: bbiswas@polarisnetworks.net
In-Reply-To: <20050628012114.71084.qmail@web308.biz.mail.mud.yahoo.com>
References: <20050628012114.71084.qmail@web308.biz.mail.mud.yahoo.com>
Content-Type: text/plain
Message-Id: <1119969031.12501.10.camel@indus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Tue, 28 Jun 2005 10:30:31 -0400
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jun 2005 14:30:45.0640 (UTC)
	FILETIME=[F87E0080:01C57BED]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: rfid@ietf.org
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

On Mon, 2005-06-27 at 21:21, Bud Biswas wrote:
> Hello Krishna:
> 
> In the RFC you state that the RNC will support both Gen-1 and Gen-2
> readers. When we send the GET_READER_INFO command to reader, don't we
> need to know the Gen type of the RFC ? Many subsequent
> command/responses are tied to C1G2 readers only. We do not need those
> when we are talking to a C0/1G1 reader.
> 

Bud,
First off, the draft proposal is not an RFC yet.
 
The protocol proposal defines the bits that go over the wire - it does
not define the reader architecture or the RNC architecture. The question
I think you are asking is how does the RNC know the capabilities of the
reader - specifically, the air protocols supported by the reader. In the
Get_reader_info command, there is a parameter called "reader
capabilities". Its encoded using a 32 bit vector - we intend to use the
bits in that field to communicate the protocol capabilities of the
reader. We have defined some bits for 

> For that matter, should not not have the other classes of tags as well
> ?
> 
Yes, ultimately we would have the air-protocol parameters specified for
the other protocols too. We currently have defined C1G1 and C1G2
parameters. As a matter of fact, we are looking to working with others
in this group for defining the other protocols. At the end of the day,
this is a group effort - we've been getting a combination of private and
public feedback and the 3 versions that we've generated have tried to
incorporate them. We look forward to contributions from others - one
obvious area is the parameter definitions for the other protocols. 

Thanks,
/Krishna


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Tue Jun 28 16:32:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnMkm-0008OR-A9; Tue, 28 Jun 2005 16:32:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMkk-0008Mo-7X
	for rfid@megatron.ietf.org; Tue, 28 Jun 2005 16:32:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19108
	for <rfid@ietf.org>; Tue, 28 Jun 2005 16:32:11 -0400 (EDT)
Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnN09-0002Lu-Bv
	for rfid@ietf.org; Tue, 28 Jun 2005 16:48:15 -0400
Received: from [192.168.1.44] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 28 Jun 2005 16:21:41 -0400
Subject: Re: [Rfid] SLRRP draft 02: Support of multiple protocols by a
	single antenna ?
From: "P. Krishna" <pkrishna@revasystems.com>
To: bbiswas@polarisnetworks.net
In-Reply-To: <20050628022004.68052.qmail@web311.biz.mail.mud.yahoo.com>
References: <20050628022004.68052.qmail@web311.biz.mail.mud.yahoo.com>
Content-Type: text/plain
Message-Id: <1119990101.12501.48.camel@indus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Tue, 28 Jun 2005 16:21:41 -0400
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jun 2005 20:21:41.0799 (UTC)
	FILETIME=[FEF0E370:01C57C1E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: rfid@ietf.org
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

On Mon, 2005-06-27 at 22:20, Bud Biswas wrote:
> Krishna:
> 
> In section 3.4.5, we are assuming that a single antenna (as designated
> by the antenna id field) can read multiple air protocol tags. This
> happens we set a value of 7 in the air protocol field implying that we
> want to read tags of types, C0G1, C1G1 and C1G2. Is this the intention
> ?

I used one-hot encoding for the air protocol field. This is to allow for
RNC to send a single inventory command for multiple-protocols. This is
only if the reader is capable of processing multi-protocol inventory
command. The RNC fills in the specific parameters for each protocol in
the command. As you stated if the value is 7, then the RNC sends
parameters for C0G1, C1G1 and C1G2 protocols along with the command.

If the reader is not capable of processing multi-protocol inventory
commands, then the RNC sends single-protocol inventory commands.

> Also, it is possible that RNC does not know the type of tags a reader
> can read. The reader is capable of only some types. Then the reader can
> send a response of what types it is supporting. Is it something
> desirable ?may be the reader has sent that info to RNC with the
> GET_READER_INFO_RESPONSE.
> 
I've already addressed this in your previous email question. I hope that
was clear.

/Krishna



_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Tue Jun 28 20:35:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnQYH-0008Vs-I1; Tue, 28 Jun 2005 20:35:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnQYG-0008Vh-RU
	for rfid@megatron.ietf.org; Tue, 28 Jun 2005 20:35:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15933
	for <rfid@ietf.org>; Tue, 28 Jun 2005 20:35:39 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: from agate.intermec.com ([63.127.92.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnQxi-00020o-DW
	for rfid@ietf.org; Tue, 28 Jun 2005 21:01:59 -0400
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BPX7>; Tue, 28 Jun 2005 19:35:43 -0500
Message-ID: <49E558014BABD711AA980002A5421C99072E613D@normail.norand.com>
To: rfid@ietf.org
Subject: RE: [Rfid] draft-krishna-slrrp-02: Data "smoothing"
Date: Tue, 28 Jun 2005 19:35:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: dd530fb5c702ad6eef32cae6dcb86145
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============1407957163=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============1407957163==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57C42.7A9F53F8"

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_01C57C42.7A9F53F8
Content-Type: text/plain

 

Hi Rob,

 

> I agree with your comments regarding the need to report tag read counts.
We provide this capability today and our solutions providers 

> find it useful.

 

Thats great.

 

> 3.5.4.5 describes Inventory timing parameters.  I suggest defining a value
(0 or -1, either number of rounds or round size) to indicate 

> continuous, non-stop reading (until inventory stop command).

 

Looks like you figured it out in your next email !!

 

> Our experience is that there's a common use-case for continuous reading,
coupled with periodic reports and "tag seen" counts.

 

Its good to know that we've covered the common use-case using slrrp while
still being able to provide deeper controls when necessary.

 

 

> I think you need two more features:

 

Excellent suggestions. 

 

> -          An option to report "tag seen" immediately when seen for the
first time.

 

Regarding "tag seen", do you see value in reporting as soon any tag is seen
for the first  time? Or do you want to go to the extent of specifying a
particular filter-pattern and only tags matching the pattern triggers a
report? As I mentioned in an earlier email yesterday, we've just defined
couple of triggers for reports and both are time-based.  The trigger field
is a byte wide - we can define a lot more triggers. Its great you point this
particular requirement out. What other triggers do you think we should
support ? Just to be in sync, we are just talking about reporting triggers -
i.e., when to send an inventory/access report back.

[Rob] The Inventory command can filter tags with the air-protocol.  I think
that's enough.  I don't see the need for a reporting filter-pattern beyond
the air-protocol filter.  A higher-level filtering pattern can be left up to
ALE.  

 

Following are the triggers:

- every inventory round

- every T time units

- as per your suggestion, upon seeing a tag for the first time
--> anything else?

[Rob] I suppose you could trigger the report on an external I/O port.  I
can't say that I've seen a use case for it.

 

Your second suggestion is external triggered reads ... 

 

> -          External triggered reads - i.e., don't read continuously but
only when triggered by a sensor.  This is necessary for European 

> duty-cycle regulatory requirements.  Otherwise, the interface can be the
same: report tags and counts periodically and optionally 

> report tags immediately when first seen.

 

Currently what we have defined is for the triggers to go back to the RNC via
the Reader Status Report. This way if the RNC has to turn around and
generate the inventory commands, it can do that - and the RNC remains
cognizant of the RF usage in the network.

The other option is to extend the Inventory Timing operation parameter - in
terms of start time, we have 2 options, a) to start now, or b) to start @ a
specific time. We may want to extend this to "start upon a defined external
trigger". The duration of the round & # of rounds are already defined in the
timing operation parameter.

 

[Rob] "Start upon a defined external trigger" is what we need for the
European duty-cycle use case.  You need to be able to "debounce" the trigger
signal - a delay works well for this (i.e., trigger on I/O and then ignore
the I/O for some period of time). 

 

Let me know if this works for you.

 

Thank you for the input - looking forward to more suggestions from you.

 

Regards,

Krishna

 

 

 

 

 

 

"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited." 

"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited." 

"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C57C42.7A9F53F8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
font-face
	{font-family:Wingdings;}
font-face
	{font-family:Tahoma;}

 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.25in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div id=3DidOWAReplyText73050>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Rob,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; I agree with your comments =
regarding
the need to report tag read counts.&nbsp; We provide this capability =
today and
our solutions providers </span></font><o:p></o:p></p>

</div>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; find it =
useful.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thats =
great.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; 3.5.4.5 describes Inventory =
timing
parameters.&nbsp; I suggest defining a value (0 or -1, either number of =
rounds
or round size) to indicate </span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; continuous, non-stop reading =
(until
inventory stop command).</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Looks like you figured it out in =
your next
email !!</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; Our experience is that =
there&#8217;s
a common use-case for continuous reading, coupled with periodic reports =
and
&#8220;tag seen&#8221; counts.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Its good to know that we've =
covered the
common use-case using slrrp while still being able to provide deeper =
controls
when necessary.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&gt; I think you need two more =
features:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Excellent suggestions. =
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&gt; -</span></font><font size=3D1 color=3Dnavy><span =
??><span
style=3D'font-size:7.0pt;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;
</span></span></font><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>An option to report &#8220;tag =
seen&#8221;
immediately when seen for the first time.</span></font><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding &quot;tag seen&quot;, do =
you see
value in reporting as soon any tag is seen for the first&nbsp; time? Or =
do you
want to go to the extent of specifying a particular filter-pattern and =
only
tags matching the pattern triggers a report? As I mentioned in an =
earlier email
yesterday, we've just defined couple of triggers for reports and both =
are
time-based.&nbsp; The trigger field is a byte wide - we can define a =
lot more
triggers. Its great you point this particular requirement out. What =
other
triggers do you think we should support ? Just to be in sync, we are =
just
talking about reporting triggers - i.e., when to send an =
inventory/access
report back.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>[Rob] The Inventory command can =
filter tags
with the air-protocol.&nbsp; I think that&#8217;s enough.&nbsp; I =
don&#8217;t
see the need for a reporting filter-pattern beyond the air-protocol
filter.&nbsp; A higher-level filtering pattern can be left up to =
ALE.&nbsp; <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Following are the =
triggers:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>- every inventory =
round</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>- every T time =
units</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>- as per your suggestion, upon =
seeing a
tag for the first time<br>
--&gt; anything else?</span></font><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>[Rob] I suppose you could trigger =
the
report on an external I/O port.&nbsp; I can&#8217;t say that I&#8217;ve =
seen a
use case for it.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Your second suggestion is external
triggered reads ... <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&gt; -</span></font><font size=3D1 color=3Dnavy><span =
??><span
style=3D'font-size:7.0pt;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;
</span></span></font><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>External triggered reads &#8211; =
i.e.,
don&#8217;t read continuously but only when triggered by a sensor. =
&nbsp;This
is necessary for European </span></font><font color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&gt; duty-cycle regulatory requirements.&nbsp; Otherwise, =
the interface
can be the same: report tags and counts periodically and optionally =
</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&gt; report tags immediately when first =
seen.</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D3
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'>&nbsp;<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>Currently what we have defined is for the triggers to go =
back to
the RNC via the Reader Status Report. This way if the RNC has to turn =
around
and generate the inventory commands, it can do that - and the =
RNC&nbsp;remains
cognizant of the RF usage in the network.</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>The other option is to extend the Inventory Timing =
operation
parameter - in terms of start time, we have 2 options, a) to start now, =
or b)
to start @ a specific time. We may want to extend this to &quot;start =
upon a
defined external trigger&quot;. The duration of the round &amp; # of =
rounds are
already defined in the timing operation parameter.</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D3
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>[Rob] &#8220;Start upon a defined =
external
trigger&#8221; is what we need for the European duty-cycle use =
case.&nbsp; You
need to be able to &#8220;debounce&#8221; the trigger signal &#8211; a =
delay
works well for this (i.e., trigger on I/O and then ignore the I/O for =
some
period of time). <o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D3
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'>&nbsp;<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>Let me know if this works for you.</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D3
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'>&nbsp;<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>Thank you for the input - looking forward to more =
suggestions from
you.</span></font><font color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D3
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'>&nbsp;<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>Regards,</span></font><font color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><st1:place
w:st=3D"on"><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;
 font-family:Arial;color:navy'>Krishna</span></font></st1:place><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D3
color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:navy'>&nbsp;<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>
<P><FONT SIZE=3D"2" FACE=3D"Arial">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>
<P><FONT FACE=3D"Arial" SIZE=3D"2">&quot;This message is intended only =
for the named recipient. If you are not the intended recipient you are =
notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly =
prohibited.&quot;  </FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C57C42.7A9F53F8--


--===============1407957163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1407957163==--




From rfid-bounces@lists.ietf.org Wed Jun 29 07:20:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnacT-000069-Pq; Wed, 29 Jun 2005 07:20:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnacT-000064-Aj
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 07:20:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05670
	for <rfid@ietf.org>; Wed, 29 Jun 2005 07:20:40 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnb1x-0002cs-VS
	for rfid@ietf.org; Wed, 29 Jun 2005 07:47:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 29 Jun 2005 07:20:19 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16E3733DA@ms08.mse3.exchange.ms>
Thread-Topic: SLRRP open source project created
Thread-Index: AcV8nIhT5ZhtGjA3SJG3hDUv8Ofagg==
From: "Scott Barvick" <sbarvick@revasystems.com>
To: <rfid@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: 
Subject: [Rfid] SLRRP open source project created
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>
Content-Type: multipart/mixed; boundary="===============0766453509=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0766453509==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57C9C.885A87CE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57C9C.885A87CE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I am pleased to announce that an open source project to implement the =
SLRRP protocol has been created on the SourceForge open source software =
site. The goal of this project is to provide an open, community =
developed implementation of the SLRRP protocol that follows the =
specification as it progresses through the standards process.=20

The project home page can be found at:
http://slrrp.sourceforge.net=20
and the project summary page can be found at:
http://sourceforge.net/projects/slrrp =20
(the two sites link to each other).

A working implementation of the draft-krishna-slrrp-02.txt has been =
released into the project to provide the starting point.   While there =
is always more to do, it does provide a good base for the community to =
take forward as SLRRP progresses.=20

Logistically, the protocol specification should continue to be discussed =
and progressed on this list, and details of the open source =
implementation (that are not base protocol related) should be directed =
to the forums on the SourceForge project site.  It is hoped that we can =
get a good base of contribution to the specification and the open source =
project from a wide variety of participants interested in an open =
standard reader protocol.=20

Please don't hesitate to ask any questions about the open source effort
or the protocol in general. =20

Thanks,
Scott

------_=_NextPart_001_01C57C9C.885A87CE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>SLRRP open source project created</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>I am pleased to announce that an open source project =
to implement the SLRRP protocol has been created on the SourceForge open =
source software site. The goal of this project is to provide an open, =
community developed implementation of the SLRRP protocol that follows =
the specification as it progresses through the standards process.<BR>
<BR>
The project home page can be found at:<BR>
<A =
HREF=3D"http://slrrp.sourceforge.net">http://slrrp.sourceforge.net</A><BR=
>
and the project summary page can be found at:<BR>
<A =
HREF=3D"http://sourceforge.net/projects/slrrp">http://sourceforge.net/pro=
jects/slrrp</A>&nbsp;<BR>
(the two sites link to each other).<BR>
<BR>
A working implementation of the draft-krishna-slrrp-02.txt has been =
released into the project to provide the starting point.&nbsp;&nbsp; =
While there is always more to do, it does provide a good base for the =
community to take forward as SLRRP progresses.<BR>
<BR>
Logistically, the protocol specification should continue to be discussed =
and progressed on this list, and details of the open source =
implementation (that are not base protocol related) should be directed =
to the forums on the SourceForge project site.&nbsp; It is hoped that we =
can get a good base of contribution to the specification and the open =
source project from a wide variety of participants interested in an open =
standard reader protocol.<BR>
<BR>
Please don't hesitate to ask any questions about the open source =
effort<BR>
or the protocol in general.&nbsp;<BR>
<BR>
Thanks,<BR>
Scott</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57C9C.885A87CE--


--===============0766453509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0766453509==--




From rfid-bounces@lists.ietf.org Wed Jun 29 13:05:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dng0K-0004tF-Ig; Wed, 29 Jun 2005 13:05:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dng0I-0004rG-V1
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 13:05:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11507
	for <rfid@ietf.org>; Wed, 29 Jun 2005 13:05:36 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DngPr-0005Zt-VU
	for rfid@ietf.org; Wed, 29 Jun 2005 13:32:06 -0400
Received: from [10.0.0.171] (account margaret HELO [10.0.0.171])
	by thingmagic.com (CommuniGate Pro SMTP 4.1.8)
	with ESMTP-TLS id 410883; Wed, 29 Jun 2005 12:59:56 -0400
Mime-Version: 1.0
Message-Id: <p06200707bee8818e650c@[10.0.0.171]>
In-Reply-To: <0E03681B885F3B4296B999E34435A16E3733DA@ms08.mse3.exchange.ms>
References: <0E03681B885F3B4296B999E34435A16E3733DA@ms08.mse3.exchange.ms>
Date: Wed, 29 Jun 2005 13:05:17 -0400
To: "Scott Barvick" <sbarvick@revasystems.com>, <rfid@ietf.org>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: [Rfid] SLRRP open source project created
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: 
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


Hi Scott,

The sourceforge web site for this project says:

"SLRRP is the Simple Lightweight RFID Reader Protocol, an IETF draft 
standard protocol used to convey configuration, control, status, and 
tag information between controllers and readers in an IP-based RFID 
network."

Unfortunately, this is incorrect, as SLRRP is not (yet, anyway) an 
IETF standard protocol of any kind, and it is certainly not a Draft 
Standard (which would imply that it has been through two steps of the 
standards process, and that interoperability has been documented). 
SLRRP is currently an individual submission Internet-Draft with no 
official standing in the IETF at all.

Are you the correct person to contact about correcting this web site? 
Or could you contact the correct people?

Margaret



At 7:20 AM -0400 6/29/05, Scott Barvick wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57C9C.885A87CE"


I am pleased to announce that an open source project to implement the 
SLRRP protocol has been created on the SourceForge open source 
software site. The goal of this project is to provide an open, 
community developed implementation of the SLRRP protocol that follows 
the specification as it progresses through the standards process.

The project home page can be found at:
<http://slrrp.sourceforge.net>http://slrrp.sourceforge.net
and the project summary page can be found at:
<http://sourceforge.net/projects/slrrp>http://sourceforge.net/projects/slrrp 
(the two sites link to each other).

A working implementation of the draft-krishna-slrrp-02.txt has been 
released into the project to provide the starting point.   While 
there is always more to do, it does provide a good base for the 
community to take forward as SLRRP progresses.

Logistically, the protocol specification should continue to be 
discussed and progressed on this list, and details of the open source 
implementation (that are not base protocol related) should be 
directed to the forums on the SourceForge project site.  It is hoped 
that we can get a good base of contribution to the specification and 
the open source project from a wide variety of participants 
interested in an open standard reader protocol.

Please don't hesitate to ask any questions about the open source effort
or the protocol in general. 

Thanks,
Scott


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Wed Jun 29 16:38:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnjK7-0004oA-UT; Wed, 29 Jun 2005 16:38:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnjK6-0004o5-Uo
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 16:38:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22967
	for <rfid@ietf.org>; Wed, 29 Jun 2005 16:38:17 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnjjh-0006IH-Gd
	for rfid@ietf.org; Wed, 29 Jun 2005 17:04:47 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] SLRRP open source project created
Date: Wed, 29 Jun 2005 16:35:06 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16E3733DE@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] SLRRP open source project created
Thread-Index: AcV8zL/StWtNc8GkS+C6LezIEMmi1gAHUkoZ
From: "Scott Barvick" <sbarvick@revasystems.com>
To: "Margaret Wasserman" <margaret@thingmagic.com>, <rfid@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0538459851=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0538459851==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57CEA.668B9E46"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57CEA.668B9E46
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Margaret,

Good catch!  It was clearly not the intent to misrepresent the status of =
the SLRRP effort in the IETF.  We will fix the wording immediately.

Thanks,
Scott


-----Original Message-----
From: Margaret Wasserman [mailto:margaret@thingmagic.com]
Sent: Wed 6/29/2005 1:05 PM
To: Scott Barvick; rfid@ietf.org
Subject: Re: [Rfid] SLRRP open source project created
=20

Hi Scott,

The sourceforge web site for this project says:

"SLRRP is the Simple Lightweight RFID Reader Protocol, an IETF draft=20
standard protocol used to convey configuration, control, status, and=20
tag information between controllers and readers in an IP-based RFID=20
network."

Unfortunately, this is incorrect, as SLRRP is not (yet, anyway) an=20
IETF standard protocol of any kind, and it is certainly not a Draft=20
Standard (which would imply that it has been through two steps of the=20
standards process, and that interoperability has been documented).=20
SLRRP is currently an individual submission Internet-Draft with no=20
official standing in the IETF at all.

Are you the correct person to contact about correcting this web site?=20
Or could you contact the correct people?

Margaret



At 7:20 AM -0400 6/29/05, Scott Barvick wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary=3D"----_=3D_NextPart_001_01C57C9C.885A87CE"


I am pleased to announce that an open source project to implement the=20
SLRRP protocol has been created on the SourceForge open source=20
software site. The goal of this project is to provide an open,=20
community developed implementation of the SLRRP protocol that follows=20
the specification as it progresses through the standards process.

The project home page can be found at:
<http://slrrp.sourceforge.net>http://slrrp.sourceforge.net
and the project summary page can be found at:
<http://sourceforge.net/projects/slrrp>http://sourceforge.net/projects/sl=
rrp=20
(the two sites link to each other).

A working implementation of the draft-krishna-slrrp-02.txt has been=20
released into the project to provide the starting point.   While=20
there is always more to do, it does provide a good base for the=20
community to take forward as SLRRP progresses.

Logistically, the protocol specification should continue to be=20
discussed and progressed on this list, and details of the open source=20
implementation (that are not base protocol related) should be=20
directed to the forums on the SourceForge project site.  It is hoped=20
that we can get a good base of contribution to the specification and=20
the open source project from a wide variety of participants=20
interested in an open standard reader protocol.

Please don't hesitate to ask any questions about the open source effort
or the protocol in general.=20

Thanks,
Scott


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



------_=_NextPart_001_01C57CEA.668B9E46
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>RE: [Rfid] SLRRP open source project created</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Margaret,<BR>
<BR>
Good catch!&nbsp; It was clearly not the intent to misrepresent the =
status of the SLRRP effort in the IETF.&nbsp; We will fix the wording =
immediately.<BR>
<BR>
Thanks,<BR>
Scott<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Margaret Wasserman [<A =
HREF=3D"mailto:margaret@thingmagic.com">mailto:margaret@thingmagic.com</A=
>]<BR>
Sent: Wed 6/29/2005 1:05 PM<BR>
To: Scott Barvick; rfid@ietf.org<BR>
Subject: Re: [Rfid] SLRRP open source project created<BR>
<BR>
<BR>
Hi Scott,<BR>
<BR>
The sourceforge web site for this project says:<BR>
<BR>
&quot;SLRRP is the Simple Lightweight RFID Reader Protocol, an IETF =
draft<BR>
standard protocol used to convey configuration, control, status, and<BR>
tag information between controllers and readers in an IP-based RFID<BR>
network.&quot;<BR>
<BR>
Unfortunately, this is incorrect, as SLRRP is not (yet, anyway) an<BR>
IETF standard protocol of any kind, and it is certainly not a Draft<BR>
Standard (which would imply that it has been through two steps of =
the<BR>
standards process, and that interoperability has been documented).<BR>
SLRRP is currently an individual submission Internet-Draft with no<BR>
official standing in the IETF at all.<BR>
<BR>
Are you the correct person to contact about correcting this web =
site?<BR>
Or could you contact the correct people?<BR>
<BR>
Margaret<BR>
<BR>
<BR>
<BR>
At 7:20 AM -0400 6/29/05, Scott Barvick wrote:<BR>
Content-class: urn:content-classes:message<BR>
Content-Type: multipart/alternative;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
boundary=3D&quot;----_=3D_NextPart_001_01C57C9C.885A87CE&quot;<BR>
<BR>
<BR>
I am pleased to announce that an open source project to implement =
the<BR>
SLRRP protocol has been created on the SourceForge open source<BR>
software site. The goal of this project is to provide an open,<BR>
community developed implementation of the SLRRP protocol that =
follows<BR>
the specification as it progresses through the standards process.<BR>
<BR>
The project home page can be found at:<BR>
&lt;<A =
HREF=3D"http://slrrp.sourceforge.net">http://slrrp.sourceforge.net</A>&gt=
;<A =
HREF=3D"http://slrrp.sourceforge.net">http://slrrp.sourceforge.net</A><BR=
>
and the project summary page can be found at:<BR>
&lt;<A =
HREF=3D"http://sourceforge.net/projects/slrrp">http://sourceforge.net/pro=
jects/slrrp</A>&gt;<A =
HREF=3D"http://sourceforge.net/projects/slrrp">http://sourceforge.net/pro=
jects/slrrp</A><BR>
(the two sites link to each other).<BR>
<BR>
A working implementation of the draft-krishna-slrrp-02.txt has been<BR>
released into the project to provide the starting point.&nbsp;&nbsp; =
While<BR>
there is always more to do, it does provide a good base for the<BR>
community to take forward as SLRRP progresses.<BR>
<BR>
Logistically, the protocol specification should continue to be<BR>
discussed and progressed on this list, and details of the open =
source<BR>
implementation (that are not base protocol related) should be<BR>
directed to the forums on the SourceForge project site.&nbsp; It is =
hoped<BR>
that we can get a good base of contribution to the specification and<BR>
the open source project from a wide variety of participants<BR>
interested in an open standard reader protocol.<BR>
<BR>
Please don't hesitate to ask any questions about the open source =
effort<BR>
or the protocol in general.<BR>
<BR>
Thanks,<BR>
Scott<BR>
<BR>
<BR>
_______________________________________________<BR>
Rfid mailing list<BR>
Rfid@lists.ietf.org<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/rfid">https://www1.ietf.or=
g/mailman/listinfo/rfid</A><BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57CEA.668B9E46--


--===============0538459851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0538459851==--




From rfid-bounces@lists.ietf.org Wed Jun 29 18:05:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnkgj-000353-OC; Wed, 29 Jun 2005 18:05:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnkgi-00032D-BU
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 18:05:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01576
	for <rfid@ietf.org>; Wed, 29 Jun 2005 18:05:41 -0400 (EDT)
Received: from web302.biz.mail.mud.yahoo.com ([68.142.199.178])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dnl6I-0004dt-Qd
	for rfid@ietf.org; Wed, 29 Jun 2005 18:32:14 -0400
Received: (qmail 28390 invoked by uid 60001); 29 Jun 2005 22:05:27 -0000
Message-ID: <20050629220527.28388.qmail@web302.biz.mail.mud.yahoo.com>
Received: from [209.6.248.193] by web302.biz.mail.mud.yahoo.com via HTTP;
	Wed, 29 Jun 2005 15:05:27 PDT
Date: Wed, 29 Jun 2005 15:05:27 -0700 (PDT)
From: Bud Biswas <bbiswas@polarisnetworks.net>
To: rfid@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
Subject: [Rfid] slrrp port number
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bbiswas@polarisnetworks.net
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>
Content-Type: multipart/mixed; boundary="===============1498752182=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

--===============1498752182==
Content-Type: multipart/alternative; boundary="0-201596609-1120082727=:26116"
Content-Transfer-Encoding: 8bit

--0-201596609-1120082727=:26116
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Scott:
 
Is there a fixed preassigned port number for the slrrp compliant reader and/or RNC ?
 
Bud


Polaris Networks
your source for rfid test tools


--0-201596609-1120082727=:26116
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Scott:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is there a fixed preassigned port number for the slrrp compliant reader and/or RNC ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bud</DIV><BR><BR><DIV>
<DIV><FONT face=arial color=#60bf00 size=3><STRONG>Polaris Networks</STRONG></FONT></DIV>
<DIV><FONT face=arial color=#0080ff><EM><STRONG>your source for rfid test tools</STRONG></EM></FONT></DIV></DIV>
--0-201596609-1120082727=:26116--


--===============1498752182==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1498752182==--




From rfid-bounces@lists.ietf.org Wed Jun 29 18:07:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnkiD-0003Pe-8W; Wed, 29 Jun 2005 18:07:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkiC-0003PZ-E5
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 18:07:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01780
	for <rfid@ietf.org>; Wed, 29 Jun 2005 18:07:14 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnl7q-0004gw-21
	for rfid@ietf.org; Wed, 29 Jun 2005 18:33:46 -0400
Received: from [10.0.0.171] (account margaret HELO [10.0.0.171])
	by thingmagic.com (CommuniGate Pro SMTP 4.1.8)
	with ESMTP-TLS id 411492; Wed, 29 Jun 2005 18:01:48 -0400
Mime-Version: 1.0
Message-Id: <p06200711bee8cbdbcec4@[10.0.0.171]>
In-Reply-To: <0E03681B885F3B4296B999E34435A16E3733DE@ms08.mse3.exchange.ms>
References: <0E03681B885F3B4296B999E34435A16E3733DE@ms08.mse3.exchange.ms>
Date: Wed, 29 Jun 2005 18:07:08 -0400
To: "Scott Barvick" <sbarvick@revasystems.com>, <rfid@ietf.org>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: RE: [Rfid] SLRRP open source project created
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: 
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


Hi Scott,

Thanks!  (And sorry for sending my previous message to the whole 
list, I only meant to send it to you.)

Margaret

At 4:35 PM -0400 6/29/05, Scott Barvick wrote:
Margaret,

Good catch!  It was clearly not the intent to misrepresent the status 
of the SLRRP effort in the IETF.  We will fix the wording immediately.

Thanks,
Scott


-----Original Message-----
From: Margaret Wasserman 
[<mailto:margaret@thingmagic.com>mailto:margaret@thingmagic.com]
Sent: Wed 6/29/2005 1:05 PM
To: Scott Barvick; rfid@ietf.org
Subject: Re: [Rfid] SLRRP open source project created


Hi Scott,

The sourceforge web site for this project says:

"SLRRP is the Simple Lightweight RFID Reader Protocol, an IETF draft
standard protocol used to convey configuration, control, status, and
tag information between controllers and readers in an IP-based RFID
network."

Unfortunately, this is incorrect, as SLRRP is not (yet, anyway) an
IETF standard protocol of any kind, and it is certainly not a Draft
Standard (which would imply that it has been through two steps of the
standards process, and that interoperability has been documented).
SLRRP is currently an individual submission Internet-Draft with no
official standing in the IETF at all.

Are you the correct person to contact about correcting this web site?
Or could you contact the correct people?

Margaret



At 7:20 AM -0400 6/29/05, Scott Barvick wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C57C9C.885A87CE"


I am pleased to announce that an open source project to implement the
SLRRP protocol has been created on the SourceForge open source
software site. The goal of this project is to provide an open,
community developed implementation of the SLRRP protocol that follows
the specification as it progresses through the standards process.

The project home page can be found at:
<<http://slrrp.sourceforge.net>http://slrrp.sourceforge.net><http://slrrp.sourceforge.net>http://slrrp.sourceforge.net
and the project summary page can be found at:
<<http://sourceforge.net/projects/slrrp>http://sourceforge.net/projects/slrrp><http://sourceforge.net/projects/slrrp>http://sourceforge.net/projects/slrrp
(the two sites link to each other).

A working implementation of the draft-krishna-slrrp-02.txt has been
released into the project to provide the starting point.   While
there is always more to do, it does provide a good base for the
community to take forward as SLRRP progresses.

Logistically, the protocol specification should continue to be
discussed and progressed on this list, and details of the open source
implementation (that are not base protocol related) should be
directed to the forums on the SourceForge project site.  It is hoped
that we can get a good base of contribution to the specification and
the open source project from a wide variety of participants
interested in an open standard reader protocol.

Please don't hesitate to ask any questions about the open source effort
or the protocol in general.

Thanks,
Scott


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
<https://www1.ietf.org/mailman/listinfo/rfid>https://www1.ietf.org/mailman/listinfo/rfid


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Wed Jun 29 19:18:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnlot-0002Vx-5A; Wed, 29 Jun 2005 19:18:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnlor-0002Ub-Is
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 19:18:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08997
	for <rfid@ietf.org>; Wed, 29 Jun 2005 19:18:10 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnmEU-0002ow-IN
	for rfid@ietf.org; Wed, 29 Jun 2005 19:44:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] slrrp port number
Date: Wed, 29 Jun 2005 19:16:10 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16E3733F2@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] slrrp port number
Thread-Index: AcV89r8KmuZ+7tOlS2KyzbjtlSAHOQACcpbd
From: "Scott Barvick" <sbarvick@revasystems.com>
To: <bbiswas@polarisnetworks.net>, <rfid@ietf.org>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============1413592045=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1413592045==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57D00.C075A92E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57D00.C075A92E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Bud,

We just picked one for the draft.  I don't know at what stage in a =
process we could get one assigned or if we can get one at any time.  =
Does anyone on the list know if IANA will give us a port at this stage?

Scott

-----Original Message-----
From: rfid-bounces@lists.ietf.org on behalf of Bud Biswas
Sent: Wed 6/29/2005 6:05 PM
To: rfid@ietf.org
Subject: [Rfid] slrrp port number
=20
Scott:
=20
Is there a fixed preassigned port number for the slrrp compliant reader =
and/or RNC ?
=20
Bud


Polaris Networks
your source for rfid test tools


------_=_NextPart_001_01C57D00.C075A92E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>RE: [Rfid] slrrp port number</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Bud,<BR>
<BR>
We just picked one for the draft.&nbsp; I don't know at what stage in a =
process we could get one assigned or if we can get one at any =
time.&nbsp; Does anyone on the list know if IANA will give us a port at =
this stage?<BR>
<BR>
Scott<BR>
<BR>
-----Original Message-----<BR>
From: rfid-bounces@lists.ietf.org on behalf of Bud Biswas<BR>
Sent: Wed 6/29/2005 6:05 PM<BR>
To: rfid@ietf.org<BR>
Subject: [Rfid] slrrp port number<BR>
<BR>
Scott:<BR>
<BR>
Is there a fixed preassigned port number for the slrrp compliant reader =
and/or RNC ?<BR>
<BR>
Bud<BR>
<BR>
<BR>
Polaris Networks<BR>
your source for rfid test tools<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57D00.C075A92E--


--===============1413592045==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1413592045==--




From rfid-bounces@lists.ietf.org Wed Jun 29 19:59:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnmT2-0007bx-2K; Wed, 29 Jun 2005 19:59:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnlxl-0005Iu-8q
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 19:27:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10071
	for <rfid@ietf.org>; Wed, 29 Jun 2005 19:27:22 -0400 (EDT)
Received: from [24.244.171.76] (helo=mail.sarbserve.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnmNO-0003nj-IZ
	for rfid@ietf.org; Wed, 29 Jun 2005 19:53:55 -0400
Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1])
	by mail.sarbserve.com (8.13.4/8.13.4/Debian-3) with ESMTP id
	j5TNQV3o022670; Wed, 29 Jun 2005 16:26:31 -0700
In-Reply-To: <0E03681B885F3B4296B999E34435A16E3733F2@ms08.mse3.exchange.ms>
References: <0E03681B885F3B4296B999E34435A16E3733F2@ms08.mse3.exchange.ms>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D543A0EC-6C26-416B-BB1A-63B81A1924E1@dbc.mtview.ca.us>
Content-Transfer-Encoding: 7bit
From: Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Re: [Rfid] slrrp port number
Date: Wed, 29 Jun 2005 16:27:05 -0700
To: Scott Barvick <sbarvick@revasystems.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 29 Jun 2005 19:59:42 -0400
Cc: rfid@ietf.org
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

> We just picked one for the draft.  I don't know at what stage in a  
> process we could get one assigned or if we can get one at any  
> time.  Does anyone on the list know if IANA will give us a port at  
> this stage?

anyone can request a port number from the iana. however, if a working  
group is formed, my guess is that the resulting document will get a  
new port number, as it will likely be somewhat different than the  
current draft...

/mtr


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Wed Jun 29 19:59:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnmT2-0007cM-D7; Wed, 29 Jun 2005 19:59:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnlyq-0006Cc-BB
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 19:28:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10246
	for <rfid@ietf.org>; Wed, 29 Jun 2005 19:28:29 -0400 (EDT)
Received: from [24.244.171.76] (helo=mail.sarbserve.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnmOT-0003qK-LL
	for rfid@ietf.org; Wed, 29 Jun 2005 19:55:03 -0400
Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1])
	by mail.sarbserve.com (8.13.4/8.13.4/Debian-3) with ESMTP id
	j5TNRpX2022688; Wed, 29 Jun 2005 16:27:51 -0700
In-Reply-To: <200506280225.j5S2PJYQ006066@cichlid.raleigh.ibm.com>
References: <200506280225.j5S2PJYQ006066@cichlid.raleigh.ibm.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FC193C0A-BC06-44F6-A4B8-F0D9C6D84582@dbc.mtview.ca.us>
Content-Transfer-Encoding: 7bit
From: Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Re: [Rfid] status of the SLRRP effort
Date: Wed, 29 Jun 2005 16:28:25 -0700
To: Thomas Narten <narten@us.ibm.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 29 Jun 2005 19:59:42 -0400
Cc: rfid@ietf.org
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

> Can someone tell me the status of this effort within the IETF?
>
> There has been relatively little traffic on the list since the
> Minneapolis BOF. I also don't recall discussion of a revised charter,
> or submission of one to the IESG for formal consideration. Finally,
> with the Paris meeting coming up, there has been no followup
> concerning whether a meeting is planned and/or what its focus would
> be.
>
> Can I assume that the conclusion of the Minneapolis BOF is that no WG
> will be formed at this time?

i think a combination of summer vacations, the usual negotiations,  
etc., have led you to an inaccurate conclusion. i have not seen  
anything in the iesg minutes to the contrary.

/mtr


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Wed Jun 29 20:18:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnmkw-0005AP-Kg; Wed, 29 Jun 2005 20: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 1Dnmku-00058V-Ug
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 20:18:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14028
	for <rfid@ietf.org>; Wed, 29 Jun 2005 20:18:11 -0400 (EDT)
From: Rob.Buck@intermec.com
Received: from agate.intermec.com ([63.127.92.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnnAZ-0007a1-Cx
	for rfid@ietf.org; Wed, 29 Jun 2005 20:44:44 -0400
Received: by normail.norand.com with Internet Mail Service (5.5.2653.19)
	id <NHN0BRQ3>; Wed, 29 Jun 2005 19:18:15 -0500
Message-ID: <49E558014BABD711AA980002A5421C99073237FF@normail.norand.com>
To: rfid@ietf.org
Subject: RE: [Rfid] slrrp port number
Date: Wed, 29 Jun 2005 19:18:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============1114232598=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

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.

--===============1114232598==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57D09.30563B64"

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_01C57D09.30563B64
Content-Type: text/plain

Our experience is that it takes ~3 months to get a port from IANA but it is
possible.

 

Rob

 

   _____  

From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On
Behalf Of Scott Barvick
Sent: Wednesday, June 29, 2005 6:16 PM
To: bbiswas@polarisnetworks.net; rfid@ietf.org
Subject: RE: [Rfid] slrrp port number

 

 

Bud,

We just picked one for the draft.  I don't know at what stage in a process
we could get one assigned or if we can get one at any time.  Does anyone on
the list know if IANA will give us a port at this stage?

Scott

-----Original Message-----
From: rfid-bounces@lists.ietf.org on behalf of Bud Biswas
Sent: Wed 6/29/2005 6:05 PM
To: rfid@ietf.org
Subject: [Rfid] slrrp port number

Scott:

Is there a fixed preassigned port number for the slrrp compliant reader
and/or RNC ?

Bud


Polaris Networks
your source for rfid test tools

"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

------_=_NextPart_001_01C57D09.30563B64
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Rfid] slrrp port number</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.25in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Our experience is that it takes ~3 =
months
to get a port from IANA but it is =
possible.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Rob<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Scott Barvick<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June =
29, 2005
6:16 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
bbiswas@polarisnetworks.net;
rfid@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [Rfid] =
slrrp port
number</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style=3D'margin-bottom:12.0pt'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Bud,<br>
<br>
We just picked one for the draft.&nbsp; I don't know at what stage in a =
process
we could get one assigned or if we can get one at any time.&nbsp; Does =
anyone
on the list know if IANA will give us a port at this stage?<br>
<br>
Scott<br>
<br>
-----Original Message-----<br>
From: rfid-bounces@lists.ietf.org on behalf of Bud Biswas<br>
Sent: Wed 6/29/2005 6:05 PM<br>
To: rfid@ietf.org<br>
Subject: [Rfid] slrrp port number<br>
<br>
Scott:<br>
<br>
Is there a fixed preassigned port number for the slrrp compliant reader =
and/or
RNC ?<br>
<br>
Bud<br>
<br>
<br>
Polaris Networks<br>
your source for rfid test tools</span></font><o:p></o:p></p>

</div>

</body>

</html>

<P><FONT SIZE=3D2 FACE=3D"Arial">"This message is intended only for the =
named recipient. If you are not the intended recipient you are notified =
that disclosing, copying, distributing or taking any action in reliance =
on the contents of this information is strictly prohibited."  =
</FONT></P>

------_=_NextPart_001_01C57D09.30563B64--


--===============1114232598==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============1114232598==--




From rfid-bounces@lists.ietf.org Wed Jun 29 20:44:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnnAB-00050f-VM; Wed, 29 Jun 2005 20:44:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnnAA-0004yy-Ah
	for rfid@megatron.ietf.org; Wed, 29 Jun 2005 20:44:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17302
	for <rfid@ietf.org>; Wed, 29 Jun 2005 20:44:17 -0400 (EDT)
Received: from ms08.mse3.exchange.ms ([69.25.50.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnnZm-0001ch-7u
	for rfid@ietf.org; Wed, 29 Jun 2005 21:10:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rfid] slrrp port number
Date: Wed, 29 Jun 2005 20:43:41 -0400
Message-ID: <0E03681B885F3B4296B999E34435A16E3733F6@ms08.mse3.exchange.ms>
Thread-Topic: [Rfid] slrrp port number
Thread-Index: AcV9CUvlyNLggtdmSJmmGj8tYfG10QAAJq99
From: "Scott Barvick" <sbarvick@revasystems.com>
To: <Rob.Buck@intermec.com>, <rfid@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399
Cc: 
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>
Content-Type: multipart/mixed; boundary="===============0494135720=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0494135720==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57D0C.C2E59141"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57D0C.C2E59141
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The draft doesn't specify a port, but the open source code has defaulted =
to 2001.  It seems prudent to not apply for a port until after the =
working group is chartered.   In any case, implementations, including =
the SourceForge code (another TODO!) should be flexible because RNCs =
should be able to listen on a non-default port and readers should be =
able to learn the port of the RNC providing the service either through =
configuration or service discovery.  =20

Scott


-----Original Message-----
From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com
Sent: Wed 6/29/2005 8:18 PM
To: rfid@ietf.org
Subject: RE: [Rfid] slrrp port number
=20
Our experience is that it takes ~3 months to get a port from IANA but it =
is possible.

=20

Rob

=20

________________________________

From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] =
On Behalf Of Scott Barvick
Sent: Wednesday, June 29, 2005 6:16 PM
To: bbiswas@polarisnetworks.net; rfid@ietf.org
Subject: RE: [Rfid] slrrp port number

=20

=20

Bud,

We just picked one for the draft.  I don't know at what stage in a =
process we could get one assigned or if we can get one at any time.  =
Does anyone on the list know if IANA will give us a port at this stage?

Scott

-----Original Message-----
From: rfid-bounces@lists.ietf.org on behalf of Bud Biswas
Sent: Wed 6/29/2005 6:05 PM
To: rfid@ietf.org
Subject: [Rfid] slrrp port number

Scott:

Is there a fixed preassigned port number for the slrrp compliant reader =
and/or RNC ?

Bud


Polaris Networks
your source for rfid test tools

"This message is intended only for the named recipient. If you are not =
the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited."=20



------_=_NextPart_001_01C57D0C.C2E59141
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>RE: [Rfid] slrrp port number</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>The draft doesn't specify a port, but the open source =
code has defaulted to 2001.&nbsp; It seems prudent to not apply for a =
port until after the working group is chartered.&nbsp;&nbsp; In any =
case, implementations, including the SourceForge code (another TODO!) =
should be flexible because RNCs should be able to listen on a =
non-default port and readers should be able to learn the port of the RNC =
providing the service either through configuration or service =
discovery.&nbsp;&nbsp;<BR>
<BR>
Scott<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: rfid-bounces@lists.ietf.org on behalf of Rob.Buck@intermec.com<BR>
Sent: Wed 6/29/2005 8:18 PM<BR>
To: rfid@ietf.org<BR>
Subject: RE: [Rfid] slrrp port number<BR>
<BR>
Our experience is that it takes ~3 months to get a port from IANA but it =
is possible.<BR>
<BR>
<BR>
<BR>
Rob<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: rfid-bounces@lists.ietf.org [<A =
HREF=3D"mailto:rfid-bounces@lists.ietf.org">mailto:rfid-bounces@lists.iet=
f.org</A>] On Behalf Of Scott Barvick<BR>
Sent: Wednesday, June 29, 2005 6:16 PM<BR>
To: bbiswas@polarisnetworks.net; rfid@ietf.org<BR>
Subject: RE: [Rfid] slrrp port number<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Bud,<BR>
<BR>
We just picked one for the draft.&nbsp; I don't know at what stage in a =
process we could get one assigned or if we can get one at any =
time.&nbsp; Does anyone on the list know if IANA will give us a port at =
this stage?<BR>
<BR>
Scott<BR>
<BR>
-----Original Message-----<BR>
From: rfid-bounces@lists.ietf.org on behalf of Bud Biswas<BR>
Sent: Wed 6/29/2005 6:05 PM<BR>
To: rfid@ietf.org<BR>
Subject: [Rfid] slrrp port number<BR>
<BR>
Scott:<BR>
<BR>
Is there a fixed preassigned port number for the slrrp compliant reader =
and/or RNC ?<BR>
<BR>
Bud<BR>
<BR>
<BR>
Polaris Networks<BR>
your source for rfid test tools<BR>
<BR>
&quot;This message is intended only for the named recipient. If you are =
not the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited.&quot;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57D0C.C2E59141--


--===============0494135720==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0494135720==--




From rfid-bounces@lists.ietf.org Thu Jun 30 02:02:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dns8Q-0002Zk-H2; Thu, 30 Jun 2005 02:02:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dns8L-0002WH-Vq
	for rfid@megatron.ietf.org; Thu, 30 Jun 2005 02:02:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17698
	for <rfid@ietf.org>; Thu, 30 Jun 2005 02:02:45 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnsY2-00026B-LT
	for rfid@ietf.org; Thu, 30 Jun 2005 02:29:20 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by sj-iport-5.cisco.com with ESMTP; 29 Jun 2005 23:02:35 -0700
X-IronPort-AV: i="3.93,243,1115017200"; 
	d="scan'208"; a="195489704:sNHT28669484"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5U62UZs023924; 
	Thu, 30 Jun 2005 02:02:30 -0400 (EDT)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 30 Jun 2005 02:02:29 -0400
Received: from 10.86.242.1 ([10.86.242.1]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) via Exchange Front-End Server email.cisco.com
	([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; 
	Thu, 30 Jun 2005 06:02:29 +0000
Received: from localhost.localdomain by email.cisco.com;
	30 Jun 2005 02:03:07 -0400
Subject: Re: [Rfid] status of the SLRRP effort
From: Ralph Droms <rdroms@cisco.com>
To: Marshall Rose <mrose@dbc.mtview.ca.us>
In-Reply-To: <FC193C0A-BC06-44F6-A4B8-F0D9C6D84582@dbc.mtview.ca.us>
References: <200506280225.j5S2PJYQ006066@cichlid.raleigh.ibm.com>
	<FC193C0A-BC06-44F6-A4B8-F0D9C6D84582@dbc.mtview.ca.us>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Thu, 30 Jun 2005 02:03:07 -0400
Message-Id: <1120111387.5877.17.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-2) 
X-OriginalArrivalTime: 30 Jun 2005 06:02:29.0691 (UTC)
	FILETIME=[4C50F8B0:01C57D39]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: rfid@ietf.org
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

Marshall - I must admit I read the following, from the "Minutes of the
March 31, 2005 IESG Teleconference", as meaning that no WG would be
formed...

   o Simple Lightweight RFID Reader Protocol (slrrp) - 1 of 1
   Token: Scott Hollenbeck

   The IESG decided not to approve the charter for the working 
   group at this time.  

Based on your e-mail, I should take this text at literal face value: the
charter was simply not approved ... but future action was not ruled out.

- Ralph

On Wed, 2005-06-29 at 16:28 -0700, Marshall Rose wrote:
> > Can someone tell me the status of this effort within the IETF?
> >
> > There has been relatively little traffic on the list since the
> > Minneapolis BOF. I also don't recall discussion of a revised charter,
> > or submission of one to the IESG for formal consideration. Finally,
> > with the Paris meeting coming up, there has been no followup
> > concerning whether a meeting is planned and/or what its focus would
> > be.
> >
> > Can I assume that the conclusion of the Minneapolis BOF is that no WG
> > will be formed at this time?
> 
> i think a combination of summer vacations, the usual negotiations,  
> etc., have led you to an inaccurate conclusion. i have not seen  
> anything in the iesg minutes to the contrary.
> 
> /mtr
> 
> 
> _______________________________________________
> Rfid mailing list
> Rfid@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/rfid

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Thu Jun 30 06:12:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnw2M-00026N-8i; Thu, 30 Jun 2005 06:12:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnw2K-00024T-NJ
	for rfid@megatron.ietf.org; Thu, 30 Jun 2005 06:12:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22230
	for <rfid@ietf.org>; Thu, 30 Jun 2005 06:12:44 -0400 (EDT)
Received: from e1.ny.us.ibm.com ([32.97.182.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnwS1-0004Es-Gu
	for rfid@ietf.org; Thu, 30 Jun 2005 06:39:22 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5UACNJ1002725
	for <rfid@ietf.org>; Thu, 30 Jun 2005 06:12:23 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id
	j5UACNKI231268 for <rfid@ietf.org>; Thu, 30 Jun 2005 06:12:23 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5UACNCB017101
	for <rfid@ietf.org>; Thu, 30 Jun 2005 06:12:23 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-65-212-63.mts.ibm.com
	[9.65.212.63])
	by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5UACL6r017056; 
	Thu, 30 Jun 2005 06:12:22 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j5UAAPO1008142;
	Thu, 30 Jun 2005 06:10:26 -0400
Message-Id: <200506301010.j5UAAPO1008142@cichlid.raleigh.ibm.com>
To: Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Re: [Rfid] status of the SLRRP effort 
In-Reply-To: Message from Marshall Rose <mrose@dbc.mtview.ca.us> of "Thu,
	30 Jun 2005 00:35:52 PDT."
	<7F6749D3-EE8F-4726-9E28-2905AA1242CB@dbc.mtview.ca.us> 
Date: Thu, 30 Jun 2005 06:10:25 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: rfid@ietf.org
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

Marshall Rose <mrose@dbc.mtview.ca.us> writes:

> the wording is poor. i am informed that a more accurate rendition is

>      at the present time, the IESG decided not to take a vote

> of course, the IESG is free to clarify as it feels appropriate.

Um, this is all rather unclear. My original question stands. What is
the status of this effort? 

If the IESG has decided not to charter the WG at this time, what are
the issues and what needs to be done?  And do people think its worth
continuing in light of the IESG issues? I don't recall seeing a
message to this list explaining the IESG action or the planned next
steps. Are those that have been working with the AD(s) to put together
a charter following up? Are there plans for a meeting in Paris?
(e.g., someone has to request a timeslot if there is to be meeting)

I'm seeing rather mixed responses from different people.

Thomas

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Thu Jun 30 08:06:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnxoj-0002rU-Lc; Thu, 30 Jun 2005 08:06:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DntgF-0006Sc-Pn
	for rfid@megatron.ietf.org; Thu, 30 Jun 2005 03:41:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13198
	for <rfid@ietf.org>; Thu, 30 Jun 2005 03:41:50 -0400 (EDT)
Received: from [24.244.171.76] (helo=mail.sarbserve.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnu5x-0004zq-HX
	for rfid@ietf.org; Thu, 30 Jun 2005 04:08:26 -0400
Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1])
	by mail.sarbserve.com (8.13.4/8.13.4/Debian-3) with ESMTP id
	j5U7eqLD031954; Thu, 30 Jun 2005 00:40:54 -0700
In-Reply-To: <1120111387.5877.17.camel@localhost.localdomain>
References: <200506280225.j5S2PJYQ006066@cichlid.raleigh.ibm.com>
	<FC193C0A-BC06-44F6-A4B8-F0D9C6D84582@dbc.mtview.ca.us>
	<1120111387.5877.17.camel@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7F6749D3-EE8F-4726-9E28-2905AA1242CB@dbc.mtview.ca.us>
Content-Transfer-Encoding: 7bit
From: Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Re: [Rfid] status of the SLRRP effort
Date: Thu, 30 Jun 2005 00:35:52 -0700
To: Ralph Droms <rdroms@cisco.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 30 Jun 2005 08:06:52 -0400
Cc: rfid@ietf.org
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


On Jun 29, 2005, at 23:03 , Ralph Droms wrote:

> Marshall - I must admit I read the following, from the "Minutes of the
> March 31, 2005 IESG Teleconference", as meaning that no WG would be
> formed...
>
>    o Simple Lightweight RFID Reader Protocol (slrrp) - 1 of 1
>    Token: Scott Hollenbeck
>
>    The IESG decided not to approve the charter for the working
>    group at this time.
>
> Based on your e-mail, I should take this text at literal face  
> value: the
> charter was simply not approved ... but future action was not ruled  
> out.

the wording is poor. i am informed that a more accurate rendition is

     at the present time, the IESG decided not to take a vote

of course, the IESG is free to clarify as it feels appropriate.

/mtr


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Thu Jun 30 09:22:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnyzl-0000Sd-QO; Thu, 30 Jun 2005 09:22:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnyzh-0000SS-4v
	for rfid@megatron.ietf.org; Thu, 30 Jun 2005 09:22:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09886
	for <rfid@ietf.org>; Thu, 30 Jun 2005 09:22:15 -0400 (EDT)
Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnzPQ-0006vV-LJ
	for rfid@ietf.org; Thu, 30 Jun 2005 09:48:54 -0400
Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 30 Jun 2005 09:21:31 -0400
Subject: Re: [Rfid] status of the SLRRP effort
From: Scott Barvick <sbarvick@revasystems.com>
To: Thomas Narten <narten@us.ibm.com>
In-Reply-To: <200506301010.j5UAAPO1008142@cichlid.raleigh.ibm.com>
References: <200506301010.j5UAAPO1008142@cichlid.raleigh.ibm.com>
Content-Type: text/plain
Message-Id: <1120137690.19550.67.camel@saco.revasystems.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Thu, 30 Jun 2005 09:21:30 -0400
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Jun 2005 13:21:31.0555 (UTC)
	FILETIME=[A14A6F30:01C57D76]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: rfid@ietf.org, Marshall Rose <mrose@dbc.mtview.ca.us>
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

Thomas,

This is a good question.  I get asked it often enough that I'll
summarize the status on the list.

After the BoF in March which was successful by all usual metrics,
Marshall and I have been actively working with Bert Wijnen to prepare
for a decision by the IESG.   The main open issue is the relationship of
the SLRRP effort to related efforts, and Bert is taking this
seriously.   Without attempting to speak for him, our action is to show
that there is support for SLRRP.   In this area, I believe it is valid
to say that support is growing.  

Some other status of the effort.  

o) There are two known (to me) implementations underway even at this
early stage in the process.   One is ours, but I'm not at liberty to say
who is doing the other one.  
o) An open source project on SourceForge has been established and
populated with a base, working implementation.  This project is intended
to have community development to fill in the implementation and
implement the protocol as it moves forward.
o) A test tool vendor (Polaris Networks) is active on the list and has
indicated that they are developing a SLRRP decoder and sniffer (on the
list).  I'm not the one to speak for them about their specific plans, of
course.  
o) We are having private conversations with folks including reader
vendors, chip makers, and application vendors who have indicated their
interest in SLRRP.  We would like this interest to become public, but
there are difficulties in some cases given that we are not yet
chartered.   
o) We continue to work with representatives from ISO and EPCGlobal to
find the appropriate working relationship among the 3 organizations.  

I hope this helps.  We are continuing to push this forward so that we
can get to a standard as quickly as possible.  If anyone wants to add to
the status, it would be great to hear about it.


Scott

On Thu, 2005-06-30 at 06:10, Thomas Narten wrote:
> Marshall Rose <mrose@dbc.mtview.ca.us> writes:
> 
> > the wording is poor. i am informed that a more accurate rendition is
> 
> >      at the present time, the IESG decided not to take a vote
> 
> > of course, the IESG is free to clarify as it feels appropriate.
> 
> Um, this is all rather unclear. My original question stands. What is
> the status of this effort? 
> 
> If the IESG has decided not to charter the WG at this time, what are
> the issues and what needs to be done?  And do people think its worth
> continuing in light of the IESG issues? I don't recall seeing a
> message to this list explaining the IESG action or the planned next
> steps. Are those that have been working with the AD(s) to put together
> a charter following up? Are there plans for a meeting in Paris?
> (e.g., someone has to request a timeslot if there is to be meeting)
> 
> I'm seeing rather mixed responses from different people.
> 
> Thomas
> 
> _______________________________________________
> Rfid mailing list
> Rfid@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/rfid


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Thu Jun 30 09:27:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dnz4z-0002E5-Fp; Thu, 30 Jun 2005 09:27:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnz4x-0002Dw-L9
	for rfid@megatron.ietf.org; Thu, 30 Jun 2005 09:27:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10384
	for <rfid@ietf.org>; Thu, 30 Jun 2005 09:27:42 -0400 (EDT)
Received: from e32.co.us.ibm.com ([32.97.110.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnzUd-00074Z-0w
	for rfid@ietf.org; Thu, 30 Jun 2005 09:54:21 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com
	[9.17.195.11])
	by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j5UDROMp742592
	for <rfid@ietf.org>; Thu, 30 Jun 2005 09:27:24 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	j5UDROIr278618 for <rfid@ietf.org>; Thu, 30 Jun 2005 07:27:24 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id
	j5UDRNFo030410 for <rfid@ietf.org>; Thu, 30 Jun 2005 07:27:23 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-212-63.mts.ibm.com
	[9.65.212.63])
	by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	j5UDRLr7030255; Thu, 30 Jun 2005 07:27:22 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j5UDPHlT014277;
	Thu, 30 Jun 2005 09:25:23 -0400
Message-Id: <200506301325.j5UDPHlT014277@cichlid.raleigh.ibm.com>
To: Scott Barvick <sbarvick@revasystems.com>
Subject: Re: [Rfid] status of the SLRRP effort 
In-Reply-To: Message from Scott Barvick <sbarvick@revasystems.com> of "Thu,
	30 Jun 2005 09:21:30 EDT."
	<1120137690.19550.67.camel@saco.revasystems.com> 
Date: Thu, 30 Jun 2005 09:25:17 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: rfid@ietf.org, Marshall Rose <mrose@dbc.mtview.ca.us>
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

Thanks Scott, your explanation helps. I asked because folk that have
asked me didn't seem to know what the exact status was.

Two more questions:

Is there a current version of the charter that reflects discussion
that has been had with the IESG, or is the charter for the "slrrp
effort" still essentially the same as the one presented at the BOF?

Second, for planning purposes, is there an expectation of a meeting in
Paris? (I'm not asking for one, just want to know if one is expected
or not.)

Thomas

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid



From rfid-bounces@lists.ietf.org Thu Jun 30 10:01:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DnzbC-0004XP-JH; Thu, 30 Jun 2005 10:01:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzbA-0004XC-IY
	for rfid@megatron.ietf.org; Thu, 30 Jun 2005 10:01:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13866
	for <rfid@ietf.org>; Thu, 30 Jun 2005 10:00:58 -0400 (EDT)
Received: from web306.biz.mail.mud.yahoo.com ([68.142.199.182])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Do00v-0001ER-Rs
	for rfid@ietf.org; Thu, 30 Jun 2005 10:27:38 -0400
Received: (qmail 72949 invoked by uid 60001); 30 Jun 2005 14:00:50 -0000
Message-ID: <20050630140050.72947.qmail@web306.biz.mail.mud.yahoo.com>
Received: from [209.6.248.193] by web306.biz.mail.mud.yahoo.com via HTTP;
	Thu, 30 Jun 2005 07:00:49 PDT
Date: Thu, 30 Jun 2005 07:00:49 -0700 (PDT)
From: Bud Biswas <bbiswas@polarisnetworks.net>
Subject: Re: [Rfid] status of the SLRRP effort
To: Scott Barvick <sbarvick@revasystems.com>
In-Reply-To: <1120137690.19550.67.camel@saco.revasystems.com>
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: rfid@ietf.org
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bbiswas@polarisnetworks.net
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>
Content-Type: multipart/mixed; boundary="===============0747898444=="
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

--===============0747898444==
Content-Type: multipart/alternative; boundary="0-1632255028-1120140049=:72803"
Content-Transfer-Encoding: 8bit

--0-1632255028-1120140049=:72803
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Scott:
 
Another point we should mention is that since the March 31 meeting at IETF, slrrp support has significantly increased in the past three months. Now I myself know of half a dozen companies who are either adding slrrp support or are "very" interested in doing so if IETF nad EPC Global can both support this.  Polaris is going ahead with a slrrp decoder/sniffer and other slrrp test tools.
 
Bud


Scott Barvick <sbarvick@revasystems.com> wrote:
Thomas,

This is a good question. I get asked it often enough that I'll
summarize the status on the list.

After the BoF in March which was successful by all usual metrics,
Marshall and I have been actively working with Bert Wijnen to prepare
for a decision by the IESG. The main open issue is the relationship of
the SLRRP effort to related efforts, and Bert is taking this
seriously. Without attempting to speak for him, our action is to show
that there is support for SLRRP. In this area, I believe it is valid
to say that support is growing. 

Some other status of the effort. 

o) There are two known (to me) implementations underway even at this
early stage in the process. One is ours, but I'm not at liberty to say
who is doing the other one. 
o) An open source project on SourceForge has been established and
populated with a base, working implementation. This project is intended
to have community development to fill in the implementation and
implement the protocol as it moves forward.
o) A test tool vendor (Polaris Networks) is active on the list and has
indicated that they are developing a SLRRP decoder and sniffer (on the
list). I'm not the one to speak for them about their specific plans, of
course. 
o) We are having private conversations with folks including reader
vendors, chip makers, and application vendors who have indicated their
interest in SLRRP. We would like this interest to become public, but
there are difficulties in some cases given that we are not yet
chartered. 
o) We continue to work with representatives from ISO and EPCGlobal to
find the appropriate working relationship among the 3 organizations. 

I hope this helps. We are continuing to push this forward so that we
can get to a standard as quickly as possible. If anyone wants to add to
the status, it would be great to hear about it.


Scott

On Thu, 2005-06-30 at 06:10, Thomas Narten wrote:
> Marshall Rose writes:
> 
> > the wording is poor. i am informed that a more accurate rendition is
> 
> > at the present time, the IESG decided not to take a vote
> 
> > of course, the IESG is free to clarify as it feels appropriate.
> 
> Um, this is all rather unclear. My original question stands. What is
> the status of this effort? 
> 
> If the IESG has decided not to charter the WG at this time, what are
> the issues and what needs to be done? And do people think its worth
> continuing in light of the IESG issues? I don't recall seeing a
> message to this list explaining the IESG action or the planned next
> steps. Are those that have been working with the AD(s) to put together
> a charter following up? Are there plans for a meeting in Paris?
> (e.g., someone has to request a timeslot if there is to be meeting)
> 
> I'm seeing rather mixed responses from different people.
> 
> Thomas
> 
> _______________________________________________
> Rfid mailing list
> Rfid@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/rfid


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid


Polaris Networks
your source for rfid test tools


--0-1632255028-1120140049=:72803
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Scott:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Another point we should mention is that since the March 31 meeting at IETF, slrrp support has significantly increased in the past three months. Now I myself&nbsp;know of&nbsp;half a dozen companies who are either adding slrrp support or are "very" interested in doing so if IETF nad EPC Global can both support this.&nbsp; Polaris is going ahead with a slrrp decoder/sniffer and other slrrp test tools.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bud</DIV>
<DIV><BR><BR><B><I>Scott Barvick &lt;sbarvick@revasystems.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Thomas,<BR><BR>This is a good question. I get asked it often enough that I'll<BR>summarize the status on the list.<BR><BR>After the BoF in March which was successful by all usual metrics,<BR>Marshall and I have been actively working with Bert Wijnen to prepare<BR>for a decision by the IESG. The main open issue is the relationship of<BR>the SLRRP effort to related efforts, and Bert is taking this<BR>seriously. Without attempting to speak for him, our action is to show<BR>that there is support for SLRRP. In this area, I believe it is valid<BR>to say that support is growing. <BR><BR>Some other status of the effort. <BR><BR>o) There are two known (to me) implementations underway even at this<BR>early stage in the process. One is ours, but I'm not at liberty to say<BR>who is doing the other one. <BR>o) An open source project on SourceForge has been established and<BR>populated wit!
 h a base,
 working implementation. This project is intended<BR>to have community development to fill in the implementation and<BR>implement the protocol as it moves forward.<BR>o) A test tool vendor (Polaris Networks) is active on the list and has<BR>indicated that they are developing a SLRRP decoder and sniffer (on the<BR>list). I'm not the one to speak for them about their specific plans, of<BR>course. <BR>o) We are having private conversations with folks including reader<BR>vendors, chip makers, and application vendors who have indicated their<BR>interest in SLRRP. We would like this interest to become public, but<BR>there are difficulties in some cases given that we are not yet<BR>chartered. <BR>o) We continue to work with representatives from ISO and EPCGlobal to<BR>find the appropriate working relationship among the 3 organizations. <BR><BR>I hope this helps. We are continuing to push this forward so that we<BR>can get to a standard as quickly as possible. If anyone wants to add
 to<BR>the status, it would be great to hear about it.<BR><BR><BR>Scott<BR><BR>On Thu, 2005-06-30 at 06:10, Thomas Narten wrote:<BR>&gt; Marshall Rose <MROSE@DBC.MTVIEW.CA.US>writes:<BR>&gt; <BR>&gt; &gt; the wording is poor. i am informed that a more accurate rendition is<BR>&gt; <BR>&gt; &gt; at the present time, the IESG decided not to take a vote<BR>&gt; <BR>&gt; &gt; of course, the IESG is free to clarify as it feels appropriate.<BR>&gt; <BR>&gt; Um, this is all rather unclear. My original question stands. What is<BR>&gt; the status of this effort? <BR>&gt; <BR>&gt; If the IESG has decided not to charter the WG at this time, what are<BR>&gt; the issues and what needs to be done? And do people think its worth<BR>&gt; continuing in light of the IESG issues? I don't recall seeing a<BR>&gt; message to this list explaining the IESG action or the planned next<BR>&gt; steps. Are those that have been working with the AD(s) to put together<BR>&gt; a charter following up? Are the!
 re plans
 for a meeting in Paris?<BR>&gt; (e.g., someone has to request a timeslot if there is to be meeting)<BR>&gt; <BR>&gt; I'm seeing rather mixed responses from different people.<BR>&gt; <BR>&gt; Thomas<BR>&gt; <BR>&gt; _______________________________________________<BR>&gt; Rfid mailing list<BR>&gt; Rfid@lists.ietf.org<BR>&gt; https://www1.ietf.org/mailman/listinfo/rfid<BR><BR><BR>_______________________________________________<BR>Rfid mailing list<BR>Rfid@lists.ietf.org<BR>https://www1.ietf.org/mailman/listinfo/rfid<BR></BLOCKQUOTE><BR><BR><DIV>
<DIV><FONT face=arial color=#60bf00 size=3><STRONG>Polaris Networks</STRONG></FONT></DIV>
<DIV><FONT face=arial color=#0080ff><EM><STRONG>your source for rfid test tools</STRONG></EM></FONT></DIV></DIV>
--0-1632255028-1120140049=:72803--


--===============0747898444==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--===============0747898444==--




From rfid-bounces@lists.ietf.org Thu Jun 30 15:14:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Do4V1-0003Ji-IF; Thu, 30 Jun 2005 15:14:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Do4Uw-0003AG-86
	for rfid@megatron.ietf.org; Thu, 30 Jun 2005 15:14:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13909
	for <rfid@ietf.org>; Thu, 30 Jun 2005 15:14:52 -0400 (EDT)
Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do4ui-0007X5-Vb
	for rfid@ietf.org; Thu, 30 Jun 2005 15:41:34 -0400
Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 30 Jun 2005 15:14:34 -0400
Subject: Re: [Rfid] status of the SLRRP effort
From: Scott Barvick <sbarvick@revasystems.com>
To: Thomas Narten <narten@us.ibm.com>
In-Reply-To: <200506301325.j5UDPHlT014277@cichlid.raleigh.ibm.com>
References: <200506301325.j5UDPHlT014277@cichlid.raleigh.ibm.com>
Content-Type: multipart/mixed; boundary="=-GWSqbnz9QCwvEDun7X50"
Message-Id: <1120158873.19550.286.camel@saco.revasystems.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date: Thu, 30 Jun 2005 15:14:33 -0400
X-OriginalArrivalTime: 30 Jun 2005 19:14:34.0839 (UTC)
	FILETIME=[F3830E70:01C57DA7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
Cc: rfid@ietf.org, Marshall Rose <mrose@dbc.mtview.ca.us>
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


--=-GWSqbnz9QCwvEDun7X50
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Thomas,

Under Bert's direction, we've been tweaking the proposed charter a bit
to get it ready for IESG review.   It is not substantively different
from what was discussed at the BoF, but it is included below so that
everyone is up to date. 

The biggest changes are:
1) A new, catchy WG name (CAIRO).  Very important :)
2) A more explicit breakout of the operations and management functions
that are not part of the actual SLRRP protocol.  These would be tackled
by the Working Group after a successful completion of the SLRRP spec. 
This has always been the advice and the plan, but the wording was a bit
ambiguous.
3) More detail on the Interaction with Other Standards Bodies and how we
would attempt to make sure that IETF output would be compatible with
outputs from the other RFID organizations.
4) Also, the milestone dates keep being updated because the remaining
dates depend on the WG charter date.  However, we do want to aggressive
and keep the relative timing as shown.

I can't say that this is what Bert will be comfortable presenting to the
IESG (he is on vacation), but this is the current state of the draft. 
Comments from the list are appreciated as we continue to tune this.

Also, I don't know what the recommendation for Paris would be given the
timing.  It doesn't seem necessary or useful to hold another BoF, but
I'm not sure that we have time to get an official working group meeting
time together.   I'll ask Bert when he gets back.
 
Scott

On Thu, 2005-06-30 at 09:25, Thomas Narten wrote:
> Thanks Scott, your explanation helps. I asked because folk that have
> asked me didn't seem to know what the exact status was.
> 
> Two more questions:
> 
> Is there a current version of the charter that reflects discussion
> that has been had with the IESG, or is the charter for the "slrrp
> effort" still essentially the same as the one presented at the BOF?
> 
> Second, for planning purposes, is there an expectation of a meeting in
> Paris? (I'm not asking for one, just want to know if one is expected
> or not.)
> 
> Thomas

--=-GWSqbnz9QCwvEDun7X50
Content-Disposition: attachment; filename=cairo.txt
Content-Type: text/plain; name=cairo.txt; charset=UTF-8
Content-Transfer-Encoding: 7bit

Control and Access of Infrastructure for RFID Operations (CAIRO) Working Group

Description of Working Group:

Radio Frequency Identification (RFID) is a technique whereby a device,
known as an RFID 'reader', can remotely sense the presence of, and
access embedded memory on, a transponder, known as a 'tag'. Tags may be
affixed to objects as a means to track the location and movement of said
objects within facilities equipped with readers. Tags may also include
environmental sensors that may capture and report conditions to which
the tag has been subjected. The tags can be stationary (attached to
fixed locations in a facility) or mobile (attached to things moving
about the facility). The readers can be stationary (attached to doors,
walls, shelving, or scaffolding) or mobile (handheld, or vehicle-
mounted).

Recently, as a result of the development of standard RF (air) protocols
and through the application of low-cost embedded computing technology,
the implementation of RFID readers has evolved from peripherals
connected to a host computer via a serial port to standalone
devices supporting TCP/IP stacks connected via wired (Ethernet) or
wireless (802.11) LAN technology to enterprise computing resources
supporting RFID-enabled client applications. This evolution has been
accompanied by substantial reader price reductions, as reader
manufacturers prepare for large-volume deployments of the technology.

We envision a typical RFID deployment comprising of a network of RFID
readers controlled by one or more reader network controller elements
(which may be software in a server, RFID reader, control blade of a
router/switch, or a standalone device). These controller elements in
turn are connected to hosts/servers running client applications that
ultimately consume the acquired tag data and management applications
that monitor the operation of the reader network.

This working group will specify a reader protocol, the Simple
Lightweight RFID Reader Protocol, or SLRRP (pronounced 'slurp') for use
in an IP-based network to convey control information to readers and status 
RF, and tag information from readers. This will be the initial priority of
the working group, and it will provide the following capabilities:

   Network Connectivity to Readers:
       * Connection establishment and state maintenance
       * Reader-controller identification definition
       * Managing reader power consumption for POE readers
       * Security considerations

   RF-domain Control:
       * Allocating RF spectrum utilization across readers
       * RF monitoring including interference detection and measurement
       * Reader co-monitoring

   Reader Control and Access:
       * Controlling tag access and tag state across readers
       * Coordinating singulation parameters and/or state across readers
       * Conveying tag data and status from readers to the controllers
       * Requesting and coordinating tag operations such as writing of tag data
       * Distributing reader-generated trigger events
       * Supporting air protocol specifics from air protocol standards bodies

In the future, the working group may specify a set of cooperating functions and 
possibly protocols that achieve the level of operations support and management 
expected of devices in today's IP network infrastructure with additional RF
controls as the products develop. 

   Operations and management of readers:
       * Discovery
       * Firmware/software configuration
       * Health monitoring
       * Connectivity monitoring
       * Statistics gathering
       * Configuration and profile management
       * Managing reader power consumption
       * Security

It is possible that work undertaken in other working groups and even 
other standards bodies (e.g. MIBs, air protocol details for SLRRP extension) 
will be referenced by this working group.  This working group will seek to 
maximize the use of existing specifications where applicable.  


Interaction With Other Standards Bodies:

There are currently two organizations that develop specifications for 
RFID air protocols, ISO and EPCGlobal.  Because the IETF will not define a 
specific RFID air protocol, the IETF is an appropriate venue for the development
of an air protocol-aware framework for RFID reader communications and
management.  This is the goal of SLRRP and subsequent WG specifications. 

Because this working group seeks to develop operations and protocols based on 
RFID operations defined in publicly available documents from recognized
standards bodies and industry consortia, a formal liaison with contributing 
organizations is not strictly required for completion of CAIRO Working 
Group deliverables.   

However, given the relationship that exists between the RFID air protocols 
and the operations required to convey the control information and tag data 
over an IP network, an open working relationship between the IETF and the air
protocol development organizations will be encouraged.  This support will 
include liaison arrangements where possible, the support of cross 
participation in the contributing air protocol standards bodies, and 
specific intermediate milestones in the Working Group development that 
will provide opportunity for feedback and input into the standards development 
process.  

It is noted here that the liberal membership policies and open development 
procedures of the IETF will always provide members of other organizations
opportunities for full awareness of technical directions as well as for 
direct technical contribution.  The co-chairs of this Working Group will 
also attempt to work with representatives of the other organizations to provide 
updates of architectural directions and technical details where possible to
the members of the Working Group so that incompatible outputs from the 
organizations can be avoided.


Goals and Milestones:

Done          Post draft-krishna-slrrp-00.txt and draft working group charter 
Done          Post updates to draft-krishna-slrrp-00.txt
Done          BoF at 62nd IETF 
June     05   Complete required charter actions
October  05   Submit SLRRP draft to EPCGlobal and ISO for comment
Dec      05   Submit SLRRP to IESG as Proposed Standard


Internet-Drafts:

http://www.ietf.org/internet-drafts/draft-krishna-slrrp-02.txt


Informational Links:
http://www.iso.org
http://www.epcglobalinc.org
http://www.rfidjournal.com














--=-GWSqbnz9QCwvEDun7X50
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid

--=-GWSqbnz9QCwvEDun7X50--