From rfid-bounces@lists.ietf.org Tue Aug 02 15:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02Jn-0006KL-0i; Tue, 02 Aug 2005 15:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02Jm-0006KG-2A for rfid@megatron.ietf.org; Tue, 02 Aug 2005 15:20:50 -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 PAA12791 for ; Tue, 2 Aug 2005 15:20:47 -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.43) id 1E02qH-0006vk-9V for rfid@ietf.org; Tue, 02 Aug 2005 15:54:27 -0400 Received: by normail.norand.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Aug 2005 14:20:48 -0500 Message-ID: <49E558014BABD711AA980002A5421C999E04DC@normail.norand.com> To: rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Tue, 2 Aug 2005 14:20:45 -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: a1852b4f554b02e7e4548cc7928acc1f 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Viewpoint from another hardware vendor: If SLRRP gains traction we'll probably want to adapt it to a reader module with a serial interface to maintain a common interface between readers. However, if SLRRP is XML-based I don't think it will be viable for serial I/O. A minimal text protocol is marginal over serial. Adding XML (even if minimal) pushes the bandwidth over the top. I agree with the human readable arguments of text vs binary. With text we've experienced lower training and support costs, faster time-to-market, etc. However, I foresee RFID development becoming more specialized with the proliferation of readers in the supply chain. It's likely that vertical application developers will only concern themselves with a high-level ALE-like interface. RFID middleware developers will grapple with the low-level interfaces. We have a group of network programmers that tell me they prefer a binary interface. They have tools (LAN analyzers, etc.) to work with binary so they're not concerned with human readable. They argue that programming to a binary interface is easier/higher performance than parsing text. Rob Buck RFID Software Architect Intermec Technologies, Corp. Ofc: 641-472-3082 Cell: 319-573-5294 -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Margaret Wasserman Sent: Saturday, July 23, 2005 8:15 AM To: Marshall Rose Cc: rfid@ietf.org Subject: Re: [Rfid] XML vs. Text vs. Binary Hi Marshall, I think we are mostly in agreement about the technical trade-offs, but for some reason that doesn't lead us to the same conclusion... At 9:16 AM +0530 7/23/05, Marshall Rose wrote: >this brings us back full circle: as soon as you have any level of >nesting, human type-in becomes problematic. as soon as you decide >that human type-in isn't mandatory, it is trivial to include a >standard library to do the heavy lifting while the humans invoke the >tool using textual commands. Yes, if there is any significant nesting, I agree that a human will not be able to type the commands in from memory and/or by glancing at a reference sheet. However, I don't see any reason why this protocol would require significant nesting, at least for the types of commands that a human is likely to use directly. With a text encoding, a human could also have certain prepared commands and be able to cut and paste them into the interface -- a command to reset autonomous operation, for example, or to set a reader to its default state. Or they could write simple scripts that would send specific commands or command sequences. >in other words, from where i sit, XML, cXML, etc., enjoy all the >drawbacks of both purist approaches. Correct, from a "human typing" standpoint, XML, cXML and a specialized text encoding are all roughly equivalent. However, in my opinion, they are all much better than a binary encoding. There are two factors involved here, and all three of these choices (XML, binary or specialized encodings) are fundamentally different WRT these factors: (1) Can the incoming stream be parsed by a widely available parser, or is a specialized parser necessary. XML parsers are available for all likely client systems, but a specialized text encoding or a binary encoding would require a specialized parser. BTW, subsetting XML _does not_ require a specialized parser. Reader vendors might want to includes a specialized (smaller or faster) parser and simply reject XML constructs that are not included in the subset, but clients could use a regular XML parser for this purpose. (2) Can text processing tools be used to send control messages and interpret the responses, or would binary processing be required. Both XML and a specialized text encoding would allow text processing of the messages and results, while a binary encoding would require binary processing. You've indicated that it is possible, with a binary encoding, for clients to run a tool that gives them text-based access. That's true, but users would need to _get_ that tool from somewhere... So, we are back to requiring specialized code on the client side to access this protocol. This isn't a religious issue with me -- I've just learned the benefits of text-based encoding the hard way, and I don't want to deal with another binary protocol... So, for the moment, we may have to just agree to disagree. We'd obviously need to resolve this before we can move ahead, though. Only a few of us have expressed any opinion on this subject. Are there others out there that have an opinion? There are two questions that I'd especially like to hear answered by specific other people on this list: (1) I'd like to hear from other reader vendors about whether they think that XML would place a prohibitive burden on their readers. It has been asserted that XML would have prohibitive system requirements for the reader. That certainly isn't true of ThingMagic's networked readers. In fact, using a standard parser, like XML, would reduce our development (especially debugging) and testing costs substantially, and would make it more likely that we would implement this protocol. (2) It would be very interesting to know if RFID users would see any benefit to a text-based encoding. Are there folks on this list who have RFID installed in real-world or even pilot installations (not just a few units in a test lab)? Do you have any opinions about whether the ability to access the reader using text-based tools from a client system that doesn't have a specialized client (or library) installed would be useful? Or do you see this as having little/no value? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid "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 Tue Aug 02 15:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02mX-0006cg-Pi; Tue, 02 Aug 2005 15:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02mU-0006cb-Nf for rfid@megatron.ietf.org; Tue, 02 Aug 2005 15:50: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 PAA14406 for ; Tue, 2 Aug 2005 15:50:28 -0400 (EDT) Received: from web305.biz.mail.mud.yahoo.com ([68.142.199.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E03Iz-0008ME-Ur for rfid@ietf.org; Tue, 02 Aug 2005 16:24:08 -0400 Received: (qmail 66437 invoked by uid 60001); 2 Aug 2005 19:50:12 -0000 Message-ID: <20050802195012.66435.qmail@web305.biz.mail.mud.yahoo.com> Received: from [209.113.192.144] by web305.biz.mail.mud.yahoo.com via HTTP; Tue, 02 Aug 2005 12:50:12 PDT Date: Tue, 2 Aug 2005 12:50:12 -0700 (PDT) From: Bud Biswas Subject: RE: [Rfid] XML vs. Text vs. Binary To: Rob.Buck@intermec.com In-Reply-To: <49E558014BABD711AA980002A5421C999E04DC@normail.norand.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2098440788==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org --===============2098440788== Content-Type: multipart/alternative; boundary="0-1377555192-1123012212=:65042" Content-Transfer-Encoding: 8bit --0-1377555192-1123012212=:65042 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I see the usefullness of both XML and binary to different vendors. Altho' it is true that programmers will generally prefer binary to work with, XML is also useful to a different user community (non programmers). My preference would be to see that Readers support binary as mandatory and XML as optional along with the Middleware supports binary as input from reader (mandatory) and XML input as optional. This will allow us to build both "thin" readers as well as "heavy duty" readers where the readers support XML also and may include the middleware software. Bud Biswas Rob.Buck@intermec.com wrote: Viewpoint from another hardware vendor: If SLRRP gains traction we'll probably want to adapt it to a reader module with a serial interface to maintain a common interface between readers. However, if SLRRP is XML-based I don't think it will be viable for serial I/O. A minimal text protocol is marginal over serial. Adding XML (even if minimal) pushes the bandwidth over the top. I agree with the human readable arguments of text vs binary. With text we've experienced lower training and support costs, faster time-to-market, etc. However, I foresee RFID development becoming more specialized with the proliferation of readers in the supply chain. It's likely that vertical application developers will only concern themselves with a high-level ALE-like interface. RFID middleware developers will grapple with the low-level interfaces. We have a group of network programmers that tell me they prefer a binary interface. They have tools (LAN analyzers, etc.) to work with binary so they're not concerned with human readable. They argue that programming to a binary interface is easier/higher performance than parsing text. Rob Buck RFID Software Architect Intermec Technologies, Corp. Ofc: 641-472-3082 Cell: 319-573-5294 -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Margaret Wasserman Sent: Saturday, July 23, 2005 8:15 AM To: Marshall Rose Cc: rfid@ietf.org Subject: Re: [Rfid] XML vs. Text vs. Binary Hi Marshall, I think we are mostly in agreement about the technical trade-offs, but for some reason that doesn't lead us to the same conclusion... At 9:16 AM +0530 7/23/05, Marshall Rose wrote: >this brings us back full circle: as soon as you have any level of >nesting, human type-in becomes problematic. as soon as you decide >that human type-in isn't mandatory, it is trivial to include a >standard library to do the heavy lifting while the humans invoke the >tool using textual commands. Yes, if there is any significant nesting, I agree that a human will not be able to type the commands in from memory and/or by glancing at a reference sheet. However, I don't see any reason why this protocol would require significant nesting, at least for the types of commands that a human is likely to use directly. With a text encoding, a human could also have certain prepared commands and be able to cut and paste them into the interface -- a command to reset autonomous operation, for example, or to set a reader to its default state. Or they could write simple scripts that would send specific commands or command sequences. >in other words, from where i sit, XML, cXML, etc., enjoy all the >drawbacks of both purist approaches. Correct, from a "human typing" standpoint, XML, cXML and a specialized text encoding are all roughly equivalent. However, in my opinion, they are all much better than a binary encoding. There are two factors involved here, and all three of these choices (XML, binary or specialized encodings) are fundamentally different WRT these factors: (1) Can the incoming stream be parsed by a widely available parser, or is a specialized parser necessary. XML parsers are available for all likely client systems, but a specialized text encoding or a binary encoding would require a specialized parser. BTW, subsetting XML _does not_ require a specialized parser. Reader vendors might want to includes a specialized (smaller or faster) parser and simply reject XML constructs that are not included in the subset, but clients could use a regular XML parser for this purpose. (2) Can text processing tools be used to send control messages and interpret the responses, or would binary processing be required. Both XML and a specialized text encoding would allow text processing of the messages and results, while a binary encoding would require binary processing. You've indicated that it is possible, with a binary encoding, for clients to run a tool that gives them text-based access. That's true, but users would need to _get_ that tool from somewhere... So, we are back to requiring specialized code on the client side to access this protocol. This isn't a religious issue with me -- I've just learned the benefits of text-based encoding the hard way, and I don't want to deal with another binary protocol... So, for the moment, we may have to just agree to disagree. We'd obviously need to resolve this before we can move ahead, though. Only a few of us have expressed any opinion on this subject. Are there others out there that have an opinion? There are two questions that I'd especially like to hear answered by specific other people on this list: (1) I'd like to hear from other reader vendors about whether they think that XML would place a prohibitive burden on their readers. It has been asserted that XML would have prohibitive system requirements for the reader. That certainly isn't true of ThingMagic's networked readers. In fact, using a standard parser, like XML, would reduce our development (especially debugging) and testing costs substantially, and would make it more likely that we would implement this protocol. (2) It would be very interesting to know if RFID users would see any benefit to a text-based encoding. Are there folks on this list who have RFID installed in real-world or even pilot installations (not just a few units in a test lab)? Do you have any opinions about whether the ability to access the reader using text-based tools from a client system that doesn't have a specialized client (or library) installed would be useful? Or do you see this as having little/no value? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid "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 Polaris Networks your source for rfid test tools --0-1377555192-1123012212=:65042 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I see the usefullness of both XML and binary to different vendors. Altho' it is true that programmers will generally prefer binary to work with, XML is also useful to a different user community (non programmers). My preference would be to see that Readers support binary as mandatory and XML as optional along with the Middleware supports binary as input from reader (mandatory) and XML input as optional. This will allow us to build both "thin" readers as well as "heavy duty" readers where the readers support XML also and may include the middleware software.
 
Bud Biswas


Rob.Buck@intermec.com wrote:
Viewpoint from another hardware vendor:

If SLRRP gains traction we'll probably want to adapt it to a reader module
with a serial interface to maintain a common interface between readers.
However, if SLRRP is XML-based I don't think it will be viable for serial
I/O. A minimal text protocol is marginal over serial. Adding XML (even if
minimal) pushes the bandwidth over the top.

I agree with the human readable arguments of text vs binary. With text
we've experienced lower training and support costs, faster time-to-market,
etc. However, I foresee RFID development becoming more specialized with the
proliferation of readers in the supply chain. It's likely that vertical
application developers will only concern themselves with a high-level
ALE-like interface. RFID middleware developers will grapple with the
low-level interfaces. We have a! group of network programmers that tell me
they prefer a binary interface. They have tools (LAN analyzers, etc.) to
work with binary so they're not concerned with human readable. They argue
that programming to a binary interface is easier/higher performance than
parsing text.

Rob Buck
RFID Software Architect
Intermec Technologies, Corp.
Ofc: 641-472-3082
Cell: 319-573-5294

-----Original Message-----
From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On
Behalf Of Margaret Wasserman
Sent: Saturday, July 23, 2005 8:15 AM
To: Marshall Rose
Cc: rfid@ietf.org
Subject: Re: [Rfid] XML vs. Text vs. Binary


Hi Marshall,

I think we are mostly in agreement about the technical trade-offs,
but for some reason that doesn't lead us to the same conclusion...

At 9:16 AM +0530 7/23/05, Marshall Rose wrote:
>this brings us back full circle: as soon as you have any level of
>nesting, human! type-in becomes problematic. as soon as you decide
>that human type-in isn't mandatory, it is trivial to include a
>standard library to do the heavy lifting while the humans invoke the
>tool using textual commands.

Yes, if there is any significant nesting, I agree that a human will
not be able to type the commands in from memory and/or by glancing at
a reference sheet. However, I don't see any reason why this protocol
would require significant nesting, at least for the types of commands
that a human is likely to use directly.

With a text encoding, a human could also have certain prepared
commands and be able to cut and paste them into the interface -- a
command to reset autonomous operation, for example, or to set a
reader to its default state. Or they could write simple scripts that
would send specific commands or command sequences.

>in other words, from where i sit, XML, cXML, etc., enjoy all the
>drawbacks of both purist approaches.

Correct, from a "human typing" standpoint, XML, cXML and a
specialized text encoding are all roughly equivalent. However, in my
opinion, they are all much better than a binary encoding.

There are two factors involved here, and all three of these choices
(XML, binary or specialized encodings) are fundamentally different
WRT these factors:

(1) Can the incoming stream be parsed by a widely available parser,
or is a specialized parser necessary. XML parsers are available for
all likely client systems, but a specialized text encoding or a
binary encoding would require a specialized parser. BTW, subsetting
XML _does not_ require a specialized parser. Reader vendors might
want to includes a specialized (smaller or faster) parser and simply
reject XML constructs that are not included in the subset, but
clients could use a regular XML parser for this purpose.

(2) Can ! text processing tools be used to send control messages and
interpret the responses, or would binary processing be required.
Both XML and a specialized text encoding would allow text processing
of the messages and results, while a binary encoding would require
binary processing.

You've indicated that it is possible, with a binary encoding, for
clients to run a tool that gives them text-based access. That's
true, but users would need to _get_ that tool from somewhere... So,
we are back to requiring specialized code on the client side to
access this protocol.

This isn't a religious issue with me -- I've just learned the
benefits of text-based encoding the hard way, and I don't want to
deal with another binary protocol... So, for the moment, we may have
to just agree to disagree. We'd obviously need to resolve this
before we can move ahead, though.

Only a few of us have expressed any opinion on this subject. Are there others out there that have an opinion? There are two questions
that I'd especially like to hear answered by specific other people on
this list:

(1) I'd like to hear from other reader vendors about whether they
think that XML would place a prohibitive burden on their readers. It
has been asserted that XML would have prohibitive system requirements
for the reader. That certainly isn't true of ThingMagic's networked
readers. In fact, using a standard parser, like XML, would reduce
our development (especially debugging) and testing costs
substantially, and would make it more likely that we would implement
this protocol.

(2) It would be very interesting to know if RFID users would see any
benefit to a text-based encoding. Are there folks on this list who
have RFID installed in real-world or even pilot installations (not
just a few units in a test lab)? Do you have any opinions about
whether the ability to access t! he reader using text-based tools from
a client system that doesn't have a specialized client (or library)
installed would be useful? Or do you see this as having little/no
value?

Margaret




_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid
"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


Polaris Networks
your source for rfid test tools
--0-1377555192-1123012212=:65042-- --===============2098440788== 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 --===============2098440788==-- From rfid-bounces@lists.ietf.org Tue Aug 02 16:31:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03QW-0002oD-IE; Tue, 02 Aug 2005 16:31:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03QU-0002nq-Vo for rfid@megatron.ietf.org; Tue, 02 Aug 2005 16:31: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 QAA15971 for ; Tue, 2 Aug 2005 16:31:48 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E03x0-0001Qb-Q9 for rfid@ietf.org; Tue, 02 Aug 2005 17:05:29 -0400 Received: by wproxy.gmail.com with SMTP id 49so166647wri for ; Tue, 02 Aug 2005 13:31:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BpGXzDqgvJEoe8caIBlsSejW7DzW5+8+BLCzypEZaQN5sEH19X9/S7cOKpJILYC+2DC82F9ChgywiXn4denj1Cxf9DSKafVhMQQ8TEu/acLFQSptTaITdhCgrTzEoCjfA7i5JmjUzgeO7h4D0bXoXI4koMU8L5H7NCsJ6SttDgs= Received: by 10.54.19.44 with SMTP id 44mr13735wrs; Tue, 02 Aug 2005 13:31:39 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Tue, 2 Aug 2005 13:31:39 -0700 (PDT) Message-ID: Date: Tue, 2 Aug 2005 16:31:39 -0400 From: Arjun Roychowdhury To: bbiswas@polarisnetworks.net Subject: Re: [Rfid] XML vs. Text vs. Binary In-Reply-To: <20050802195012.66435.qmail@web305.biz.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <49E558014BABD711AA980002A5421C999E04DC@normail.norand.com> <20050802195012.66435.qmail@web305.biz.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org, Rob.Buck@intermec.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org I am new to the RFID ietf group - however, I do believe it is normal at the IETF to author requirement documents in situations like this when there are clearly benefits of both XML and Binary. There have been several discussions in various groups about XML vs. Binary and unless there are clearly agreed upon requirements for the protocol in question, I am pretty sure the discussions will never converge. In the past, there have been other protocols that support both XML and binary 'profiles' - however, that does add cost & complexity for the vendor community. There are two obvious disadvantages to XML - size and speed. However, unless there is some concrete discussion on what really size and speed means relative to the requirements of this interface, that discussion cannot conclude, again. I come from the applications space (VoIP, specifically) and my current interest in RFID network side protocol lies in how to tie it with the application layer protocol (for location based services) and therefore naturally think XML suits better for this need. However, I would love to see a specific requirement document that gives this community a chance to discuss this issue in a more structured manner. regds arjun On 8/2/05, Bud Biswas wrote: > I see the usefullness of both XML and binary to different vendors. Altho'= it > is true that programmers will generally prefer binary to work with, XML i= s > also useful to a different user community (non programmers). My preferenc= e > would be to see that Readers support binary as mandatory and XML as optio= nal > along with the Middleware supports binary as input from reader (mandatory= ) > and XML input as optional. This will allow us to build both "thin" reader= s > as well as "heavy duty" readers where the readers support XML also and ma= y > include the middleware software. > =20 > Bud Biswas >=20 >=20 > Rob.Buck@intermec.com wrote: > Viewpoint from another hardware vendor:=20 >=20 > If SLRRP gains traction we'll probably want to adapt it to a reader modul= e > with a serial interface to maintain a common interface between readers. > However, if SLRRP is XML-based I don't think it will be viable for serial > I/O. A minimal text protocol is marginal over serial. Adding XML (even if > minimal) pushes the bandwidth over the top. >=20 > I agree with the human readable arguments of text vs binary. With text > we've experienced lower training and support costs, faster time-to-market= , > etc. However, I foresee RFID development becoming more specialized with t= he > proliferation of readers in the supply chain. It's likely that vertical > application developers will only concern themselves with a high-level > ALE-like interface. RFID middleware developers will grapple with the > low-level interfaces. We have a! group of network programmers that tell m= e > they prefer a binary interface. They have tools (LAN analyzers, etc.) to > work with binary so they're not concerned with human readable. They argue > that programming to a binary interface is easier/higher performance than > parsing text. >=20 > Rob Buck > RFID Software Architect > Intermec Technologies, Corp. > Ofc: 641-472-3082 > Cell: 319-573-5294 >=20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Saturday, July 23, 2005 8:15 AM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: Re: [Rfid] XML vs. Text vs. Binary >=20 >=20 > Hi Marshall, >=20 > I think we are mostly in agreement about the technical trade-offs,=20 > but for some reason that doesn't lead us to the same conclusion... >=20 > At 9:16 AM +0530 7/23/05, Marshall Rose wrote: > >this brings us back full circle: as soon as you have any level of=20 > >nesting, human! type-in becomes problematic. as soon as you decide=20 > >that human type-in isn't mandatory, it is trivial to include a=20 > >standard library to do the heavy lifting while the humans invoke the=20 > >tool using textual commands. >=20 > Yes, if there is any significant nesting, I agree that a human will=20 > not be able to type the commands in from memory and/or by glancing at=20 > a reference sheet. However, I don't see any reason why this protocol=20 > would require significant nesting, at least for the types of commands=20 > that a human is likely to use directly. >=20 > With a text encoding, a human could also have certain prepared=20 > commands and be able to cut and paste them into the interface -- a=20 > command to reset autonomous operation, for example, or to set a=20 > reader to its default state. Or they could write simple scripts that=20 > would send specific commands or command sequences. >=20 > >in other words, from where i sit, XML, cXML, etc., enjoy all the=20 > >drawbacks of both purist approaches. >=20 > Correct, from a "human typing" standpoint, XML, cXML and a=20 > specialized text encoding are all roughly equivalent. However, in my=20 > opinion, they are all much better than a binary encoding. >=20 > There are two factors involved here, and all three of these choices=20 > (XML, binary or specialized encodings) are fundamentally different=20 > WRT these factors: >=20 > (1) Can the incoming stream be parsed by a widely available parser,=20 > or is a specialized parser necessary. XML parsers are available for=20 > all likely client systems, but a specialized text encoding or a=20 > binary encoding would require a specialized parser. BTW, subsetting=20 > XML _does not_ require a specialized parser. Reader vendors might=20 > want to includes a specialized (smaller or faster) parser and simply=20 > reject XML constructs that are not included in the subset, but=20 > clients could use a regular XML parser for this purpose. >=20 > (2) Can ! text processing tools be used to send control messages and=20 > interpret the responses, or would binary processing be required.=20 > Both XML and a specialized text encoding would allow text processing=20 > of the messages and results, while a binary encoding would require=20 > binary processing. >=20 > You've indicated that it is possible, with a binary encoding, for=20 > clients to run a tool that gives them text-based access. That's=20 > true, but users would need to _get_ that tool from somewhere... So,=20 > we are back to requiring specialized code on the client side to=20 > access this protocol. >=20 > This isn't a religious issue with me -- I've just learned the=20 > benefits of text-based encoding the hard way, and I don't want to=20 > deal with another binary protocol... So, for the moment, we may have=20 > to just agree to disagree. We'd obviously need to resolve this=20 > before we can move ahead, though. >=20 > Only a few of us have expressed any opinion on this subject. Are there > others out there that have an opinion? There are two questions=20 > that I'd especially like to hear answered by specific other people on=20 > this list: >=20 > (1) I'd like to hear from other reader vendors about whether they=20 > think that XML would place a prohibitive burden on their readers. It=20 > has been asserted that XML would have prohibitive system requirements=20 > for the reader. That certainly isn't true of ThingMagic's networked=20 > readers. In fact, using a standard parser, like XML, would reduce=20 > our development (especially debugging) and testing costs=20 > substantially, and would make it more likely that we would implement=20 > this protocol. >=20 > (2) It would be very interesting to know if RFID users would see any=20 > benefit to a text-based encoding. Are there folks on this list who=20 > have RFID installed in real-world or even pilot installations (not=20 > just a few units in a test lab)? Do you have any opinions about=20 > whether the ability to access t! he reader using text-based tools from=20 > a client system that doesn't have a specialized client (or library)=20 > installed would be useful? Or do you see this as having little/no=20 > value? >=20 > Margaret >=20 >=20 >=20 >=20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > "This message is intended only for the named recipient. If you are not th= e > intended recipient you are notified that disclosing, copying, distributin= g > or taking any action in reliance on the contents of this information is > strictly prohibited."=20 >=20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid >=20 >=20 >=20 > Polaris Networks > your source for rfid test tools > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid >=20 >=20 >=20 --=20 Arjun Roychowdhury _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Tue Aug 02 17:25:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04Gm-0004Y8-4K; Tue, 02 Aug 2005 17:25:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04Gj-0004UI-7x for rfid@megatron.ietf.org; Tue, 02 Aug 2005 17:25:50 -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 RAA18053 for ; Tue, 2 Aug 2005 17:25:44 -0400 (EDT) Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E04nF-0003K9-HH for rfid@ietf.org; Tue, 02 Aug 2005 17:59:26 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 17:25:12 -0400 Subject: RE: [Rfid] XML vs. Text vs. Binary From: Scott Barvick To: bbiswas@polarisnetworks.net In-Reply-To: <20050802195012.66435.qmail@web305.biz.mail.mud.yahoo.com> References: <20050802195012.66435.qmail@web305.biz.mail.mud.yahoo.com> Content-Type: text/plain Message-Id: <1123017911.20139.651.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 02 Aug 2005 17:25:11 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Aug 2005 21:25:12.0478 (UTC) FILETIME=[AABD9BE0:01C597A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org, Rob.Buck@intermec.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Rob and Bud raise a topic that has not yet been fully addressed in the midst of this discussion - the notion of multiple representations of the protocol. This is even different from the carrying the PDUs over multiple transports (e.g. TCP, serial, ethernet). As raised in a previous thread, the concept of supporting transport of SLRRP PDUs over a non-TCP (serial) transport, while not currently in the initial SLRRP scope, does not seem to pose a significant burden in terms of specifying, implementing, or testing. All of the differences are isolated in the transport, and the same core protocol code is executed regardless of how you transport the PDUs to a particular peer. However, the idea of specifying different encodings (profiles), particularly in the case of human readable vs. binary is something that I feel would not result in an efficient standard nor an efficient standard development experience. You end up with not a single protocol, but as many protocols as you have representations, and the only thing common about them may be an initial capabilities exchange. Each representation then needs the full round of functional, system, and interoperability testing that would go with any new protocol. Of course, interoperability in this sense means only between implementations of the same encoding, not implicitly for the all encodings of the protocol. The base goals to date have been to focus on a single representation that would have the widest applicability so that a standard could be developed and deployed as quickly as possible. My thoughts only, of course. I'm sure there are others out there. Scott On Tue, 2005-08-02 at 15:50, Bud Biswas wrote: > I see the usefullness of both XML and binary to different vendors. > Altho' it is true that programmers will generally prefer binary to > work with, XML is also useful to a different user community (non > programmers). My preference would be to see that Readers support > binary as mandatory and XML as optional along with the Middleware > supports binary as input from reader (mandatory) and XML input as > optional. This will allow us to build both "thin" readers as well as > "heavy duty" readers where the readers support XML also and may > include the middleware software. > > Bud Biswas > > Rob.Buck@intermec.com wrote: > Viewpoint from another hardware vendor: > > If SLRRP gains traction we'll probably want to adapt it to a > reader module > with a serial interface to maintain a common interface between > readers. > However, if SLRRP is XML-based I don't think it will be viable > for serial > I/O. A minimal text protocol is marginal over serial. Adding > XML (even if > minimal) pushes the bandwidth over the top. > > I agree with the human readable arguments of text vs binary. > With text > we've experienced lower training and support costs, faster > time-to-market, > etc. However, I foresee RFID development becoming more > specialized with the > proliferation of readers in the supply chain. It's likely that > vertical > application developers will only concern themselves with a > high-level > ALE-like interface. RFID middleware developers will grapple > with the > low-level interfaces. We have a! group of network programmers > that tell me > they prefer a binary interface. They have tools (LAN > analyzers, etc.) to > work with binary so they're not concerned with human readable. > They argue > that programming to a binary interface is easier/higher > performance than > parsing text. > > Rob Buck > RFID Software Architect > Intermec Technologies, Corp. > Ofc: 641-472-3082 > Cell: 319-573-5294 > > -----Original Message----- > From: rfid-bounces@lists.ietf.org > [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Saturday, July 23, 2005 8:15 AM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: Re: [Rfid] XML vs. Text vs. Binary > > > Hi Marshall, > > I think we are mostly in agreement about the technical > trade-offs, > but for some reason that doesn't lead us to the same > conclusion... > > At 9:16 AM +0530 7/23/05, Marshall Rose wrote: > >this brings us back full circle: as soon as you have any > level of > >nesting, human! type-in becomes problematic. as soon as you > decide > >that human type-in isn't mandatory, it is trivial to include > a > >standard library to do the heavy lifting while the humans > invoke the > >tool using textual commands. > > Yes, if there is any significant nesting, I agree that a human > will > not be able to type the commands in from memory and/or by > glancing at > a reference sheet. However, I don't see any reason why this > protocol > would require significant nesting, at least for the types of > commands > that a human is likely to use directly. > > With a text encoding, a human could also have certain prepared > commands and be able to cut and paste them into the interface > -- a > command to reset autonomous operation, for example, or to set > a > reader to its default state. Or they could write simple > scripts that > would send specific commands or command sequences. > > >in other words, from where i sit, XML, cXML, etc., enjoy all > the > >drawbacks of both purist approaches. > > Correct, from a "human typing" standpoint, XML, cXML and a > specialized text encoding are all roughly equivalent. However, > in my > opinion, they are all much better than a binary encoding. > > There are two factors involved here, and all three of these > choices > (XML, binary or specialized encodings) are fundamentally > different > WRT these factors: > > (1) Can the incoming stream be parsed by a widely available > parser, > or is a specialized parser necessary. XML parsers are > available for > all likely client systems, but a specialized text encoding or > a > binary encoding would require a specialized parser. BTW, > subsetting > XML _does not_ require a specialized parser. Reader vendors > might > want to includes a specialized (smaller or faster) parser and > simply > reject XML constructs that are not included in the subset, but > clients could use a regular XML parser for this purpose. > > (2) Can ! text processing tools be used to send control > messages and > interpret the responses, or would binary processing be > required. > Both XML and a specialized text encoding would allow text > processing > of the messages and results, while a binary encoding would > require > binary processing. > > You've indicated that it is possible, with a binary encoding, > for > clients to run a tool that gives them text-based access. > That's > true, but users would need to _get_ that tool from > somewhere... So, > we are back to requiring specialized code on the client side > to > access this protocol. > > This isn't a religious issue with me -- I've just learned the > benefits of text-based encoding the hard way, and I don't want > to > deal with another binary protocol... So, for the moment, we > may have > to just agree to disagree. We'd obviously need to resolve this > before we can move ahead, though. > > Only a few of us have expressed any opinion on this subject. > Are there others out there that have an opinion? There are two > questions > that I'd especially like to hear answered by specific other > people on > this list: > > (1) I'd like to hear from other reader vendors about whether > they > think that XML would place a prohibitive burden on their > readers. It > has been asserted that XML would have prohibitive system > requirements > for the reader. That certainly isn't true of ThingMagic's > networked > readers. In fact, using a standard parser, like XML, would > reduce > our development (especially debugging) and testing costs > substantially, and would make it more likely that we would > implement > this protocol. > > (2) It would be very interesting to know if RFID users would > see any > benefit to a text-based encoding. Are there folks on this list > who > have RFID installed in real-world or even pilot installations > (not > just a few units in a test lab)? Do you have any opinions > about > whether the ability to access t! he reader using text-based > tools from > a client system that doesn't have a specialized client (or > library) > installed would be useful? Or do you see this as having > little/no > value? > > Margaret > > > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > "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 > > > Polaris Networks > your source for rfid test tools > > ______________________________________________________________________ > _______________________________________________ > 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 Aug 03 00:38:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0B1o-00028E-BX; Wed, 03 Aug 2005 00:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0B1m-00023i-44 for rfid@megatron.ietf.org; Wed, 03 Aug 2005 00:38:50 -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 AAA06860 for ; Wed, 3 Aug 2005 00:38:46 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0BYM-00021V-Vd for rfid@ietf.org; Wed, 03 Aug 2005 01:12:32 -0400 Received: from ([10.100.101.65]) by relay3.manh.com with ESMTP id 4029073.8246970; Wed, 03 Aug 2005 00:37:37 -0400 Received: from ma-atl96.us.manh.com ([10.100.101.96]) by ma-atl63 with trend_isnt_name_B; Wed, 03 Aug 2005 00:37:37 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl96.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 00:37:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Wed, 3 Aug 2005 00:37:36 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEDCD@ma-atl57.us.manh.com> Thread-Topic: [Rfid] XML vs. Text vs. Binary Thread-Index: AcWXqPmdYiKHDcbzSa6g4sEfo9xmbAAOuPmg From: "Howard Kapustein" To: X-OriginalArrivalTime: 03 Aug 2005 04:37:37.0050 (UTC) FILETIME=[12E91FA0:01C597E5] X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org >The base goals to date have been to focus on >a single representation that would have the widest applicability so that The hard part is defining 'one' syntax which is widely acceptable. On good days it seems eminently reasonable and do-able. On others...one wonders how hard herding cats really is... >a standard could be developed and deployed as quickly as possible. Admirable goal. Of course, this has to balance against the other targets - how'd that go? Fast, Small, Cheap, Quality, Durability, Quick to do, Easy to use -- which are more (or less) important, and to what degree? Are the goals, constraints and assumptions underlying the solution called SLRRP clearly documented? Where? This seems to be a critical linchpin for many of these differences of opinion -- some are subjective, but lacking a clearly and commonly understood set of requirements seems to be at the heart of many of these discussions. XML vs. Binary (among other things) can be argued ad nauseum to no end, and everyone is right *and* wrong. But given a clearly documented set of requirements, people may disagree over priorities of the facts, but the facts remain. Wouldn't solve all these debates, but would bring a measure of rational and objective measurement. - Howard =20 -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Scott Barvick Sent: Tuesday, August 02, 2005 5:25 PM To: bbiswas@polarisnetworks.net Cc: rfid@ietf.org; Rob.Buck@intermec.com Subject: RE: [Rfid] XML vs. Text vs. Binary Rob and Bud raise a topic that has not yet been fully addressed in the midst of this discussion - the notion of multiple representations of the protocol. =20 This is even different from the carrying the PDUs over multiple transports (e.g. TCP, serial, ethernet). As raised in a previous thread, the concept of supporting transport of SLRRP PDUs over a non-TCP (serial) transport, while not currently in the initial SLRRP scope, does not seem to pose a significant burden in terms of specifying, implementing, or testing. All of the differences are isolated in the transport, and the same core protocol code is executed regardless of how you transport the PDUs to a particular peer. =20 However, the idea of specifying different encodings (profiles), particularly in the case of human readable vs. binary is something that I feel would not result in an efficient standard nor an efficient standard development experience. You end up with not a single protocol, but as many protocols as you have representations, and the only thing common about them may be an initial capabilities exchange. Each representation then needs the full round of functional, system, and interoperability testing that would go with any new protocol. Of course, interoperability in this sense means only between implementations of the same encoding, not implicitly for the all encodings of the protocol. The base goals to date have been to focus on a single representation that would have the widest applicability so that a standard could be developed and deployed as quickly as possible.=20 My thoughts only, of course. I'm sure there are others out there. Scott =20 On Tue, 2005-08-02 at 15:50, Bud Biswas wrote: > I see the usefullness of both XML and binary to different vendors. > Altho' it is true that programmers will generally prefer binary to > work with, XML is also useful to a different user community (non > programmers). My preference would be to see that Readers support > binary as mandatory and XML as optional along with the Middleware > supports binary as input from reader (mandatory) and XML input as > optional. This will allow us to build both "thin" readers as well as > "heavy duty" readers where the readers support XML also and may > include the middleware software. > =20 > Bud Biswas >=20 > Rob.Buck@intermec.com wrote: > Viewpoint from another hardware vendor:=20 > =20 > If SLRRP gains traction we'll probably want to adapt it to a > reader module > with a serial interface to maintain a common interface between > readers. > However, if SLRRP is XML-based I don't think it will be viable > for serial > I/O. A minimal text protocol is marginal over serial. Adding > XML (even if > minimal) pushes the bandwidth over the top. > =20 > I agree with the human readable arguments of text vs binary. > With text > we've experienced lower training and support costs, faster > time-to-market, > etc. However, I foresee RFID development becoming more > specialized with the > proliferation of readers in the supply chain. It's likely that > vertical > application developers will only concern themselves with a > high-level > ALE-like interface. RFID middleware developers will grapple > with the > low-level interfaces. We have a! group of network programmers > that tell me > they prefer a binary interface. They have tools (LAN > analyzers, etc.) to > work with binary so they're not concerned with human readable. > They argue > that programming to a binary interface is easier/higher > performance than > parsing text. > =20 > Rob Buck > RFID Software Architect > Intermec Technologies, Corp. > Ofc: 641-472-3082 > Cell: 319-573-5294 > =20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org > [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Saturday, July 23, 2005 8:15 AM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: Re: [Rfid] XML vs. Text vs. Binary > =20 > =20 > Hi Marshall, > =20 > I think we are mostly in agreement about the technical > trade-offs,=20 > but for some reason that doesn't lead us to the same > conclusion... > =20 > At 9:16 AM +0530 7/23/05, Marshall Rose wrote: > >this brings us back full circle: as soon as you have any > level of=20 > >nesting, human! type-in becomes problematic. as soon as you > decide=20 > >that human type-in isn't mandatory, it is trivial to include > a=20 > >standard library to do the heavy lifting while the humans > invoke the=20 > >tool using textual commands. > =20 > Yes, if there is any significant nesting, I agree that a human > will=20 > not be able to type the commands in from memory and/or by > glancing at=20 > a reference sheet. However, I don't see any reason why this > protocol=20 > would require significant nesting, at least for the types of > commands=20 > that a human is likely to use directly. > =20 > With a text encoding, a human could also have certain prepared > commands and be able to cut and paste them into the interface > -- a=20 > command to reset autonomous operation, for example, or to set > a=20 > reader to its default state. Or they could write simple > scripts that=20 > would send specific commands or command sequences. > =20 > >in other words, from where i sit, XML, cXML, etc., enjoy all > the=20 > >drawbacks of both purist approaches. > =20 > Correct, from a "human typing" standpoint, XML, cXML and a=20 > specialized text encoding are all roughly equivalent. However, > in my=20 > opinion, they are all much better than a binary encoding. > =20 > There are two factors involved here, and all three of these > choices=20 > (XML, binary or specialized encodings) are fundamentally > different=20 > WRT these factors: > =20 > (1) Can the incoming stream be parsed by a widely available > parser,=20 > or is a specialized parser necessary. XML parsers are > available for=20 > all likely client systems, but a specialized text encoding or > a=20 > binary encoding would require a specialized parser. BTW, > subsetting=20 > XML _does not_ require a specialized parser. Reader vendors > might=20 > want to includes a specialized (smaller or faster) parser and > simply=20 > reject XML constructs that are not included in the subset, but > clients could use a regular XML parser for this purpose. > =20 > (2) Can ! text processing tools be used to send control > messages and=20 > interpret the responses, or would binary processing be > required.=20 > Both XML and a specialized text encoding would allow text > processing=20 > of the messages and results, while a binary encoding would > require=20 > binary processing. > =20 > You've indicated that it is possible, with a binary encoding, > for=20 > clients to run a tool that gives them text-based access. > That's=20 > true, but users would need to _get_ that tool from > somewhere... So,=20 > we are back to requiring specialized code on the client side > to=20 > access this protocol. > =20 > This isn't a religious issue with me -- I've just learned the=20 > benefits of text-based encoding the hard way, and I don't want > to=20 > deal with another binary protocol... So, for the moment, we > may have=20 > to just agree to disagree. We'd obviously need to resolve this > before we can move ahead, though. > =20 > Only a few of us have expressed any opinion on this subject. > Are there others out there that have an opinion? There are two > questions=20 > that I'd especially like to hear answered by specific other > people on=20 > this list: > =20 > (1) I'd like to hear from other reader vendors about whether > they=20 > think that XML would place a prohibitive burden on their > readers. It=20 > has been asserted that XML would have prohibitive system > requirements=20 > for the reader. That certainly isn't true of ThingMagic's > networked=20 > readers. In fact, using a standard parser, like XML, would > reduce=20 > our development (especially debugging) and testing costs=20 > substantially, and would make it more likely that we would > implement=20 > this protocol. > =20 > (2) It would be very interesting to know if RFID users would > see any=20 > benefit to a text-based encoding. Are there folks on this list > who=20 > have RFID installed in real-world or even pilot installations > (not=20 > just a few units in a test lab)? Do you have any opinions > about=20 > whether the ability to access t! he reader using text-based > tools from=20 > a client system that doesn't have a specialized client (or > library)=20 > installed would be useful? Or do you see this as having > little/no=20 > value? > =20 > Margaret > =20 > =20 > =20 > =20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > "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 > =20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid >=20 >=20 > Polaris Networks > your source for rfid test tools >=20 > ______________________________________________________________________ > _______________________________________________ > 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 _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Wed Aug 03 09:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0J8u-0004mV-M0; Wed, 03 Aug 2005 09:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0J8s-0004iz-7q for rfid@megatron.ietf.org; Wed, 03 Aug 2005 09:18: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 JAA14659 for ; Wed, 3 Aug 2005 09:18:40 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JfU-0000IL-Ut for rfid@ietf.org; Wed, 03 Aug 2005 09:52:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Wed, 3 Aug 2005 09:18:17 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16E0134502F@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] XML vs. Text vs. Binary Thread-Index: AcWXqPmdYiKHDcbzSa6g4sEfo9xmbAAOuPmgABF8wNI= From: "Scott Barvick" To: "Howard Kapustein" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 41b2d478fce1e393ae0364b4260b8758 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1866153457==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1866153457== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5982D.CFB2FFF9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5982D.CFB2FFF9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Howard, I keep pointing to the proposed charter from the BoF, the subsequent = update, and the early SLRRP drafts as the set of motivations and goals = for the effort. That is what was published and used to establish the = initial interest, and, based on advice from experienced IETFers, frame a = scope for a WG that could provide an initial standard development = success in an area that needs a standard. Questions continue about the existence of goals and requirements. Are = there specific things in the proposed charter that need to be discussed? = If so we should do that. Or, are we looking to answer a question such = as the XML vs. binary question by pointing to a line that is or is not = yet in the charter? =20 Scott -----Original Message----- From: rfid-bounces@lists.ietf.org on behalf of Howard Kapustein Sent: Wed 8/3/2005 12:37 AM To: rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary =20 >The base goals to date have been to focus on >a single representation that would have the widest applicability so that The hard part is defining 'one' syntax which is widely acceptable. On good days it seems eminently reasonable and do-able. On others...one wonders how hard herding cats really is... >a standard could be developed and deployed as quickly as possible. Admirable goal. Of course, this has to balance against the other targets - how'd that go? Fast, Small, Cheap, Quality, Durability, Quick to do, Easy to use -- which are more (or less) important, and to what degree? Are the goals, constraints and assumptions underlying the solution called SLRRP clearly documented? Where? This seems to be a critical linchpin for many of these differences of opinion -- some are subjective, but lacking a clearly and commonly understood set of requirements seems to be at the heart of many of these discussions. XML vs. Binary (among other things) can be argued ad nauseum to no end, and everyone is right *and* wrong. But given a clearly documented set of requirements, people may disagree over priorities of the facts, but the facts remain. Wouldn't solve all these debates, but would bring a measure of rational and objective measurement. - Howard =20 -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Scott Barvick Sent: Tuesday, August 02, 2005 5:25 PM To: bbiswas@polarisnetworks.net Cc: rfid@ietf.org; Rob.Buck@intermec.com Subject: RE: [Rfid] XML vs. Text vs. Binary Rob and Bud raise a topic that has not yet been fully addressed in the midst of this discussion - the notion of multiple representations of the protocol. =20 This is even different from the carrying the PDUs over multiple transports (e.g. TCP, serial, ethernet). As raised in a previous thread, the concept of supporting transport of SLRRP PDUs over a non-TCP (serial) transport, while not currently in the initial SLRRP scope, does not seem to pose a significant burden in terms of specifying, implementing, or testing. All of the differences are isolated in the transport, and the same core protocol code is executed regardless of how you transport the PDUs to a particular peer. =20 However, the idea of specifying different encodings (profiles), particularly in the case of human readable vs. binary is something that I feel would not result in an efficient standard nor an efficient standard development experience. You end up with not a single protocol, but as many protocols as you have representations, and the only thing common about them may be an initial capabilities exchange. Each representation then needs the full round of functional, system, and interoperability testing that would go with any new protocol. Of course, interoperability in this sense means only between implementations of the same encoding, not implicitly for the all encodings of the protocol. The base goals to date have been to focus on a single representation that would have the widest applicability so that a standard could be developed and deployed as quickly as possible.=20 My thoughts only, of course. I'm sure there are others out there. Scott =20 On Tue, 2005-08-02 at 15:50, Bud Biswas wrote: > I see the usefullness of both XML and binary to different vendors. > Altho' it is true that programmers will generally prefer binary to > work with, XML is also useful to a different user community (non > programmers). My preference would be to see that Readers support > binary as mandatory and XML as optional along with the Middleware > supports binary as input from reader (mandatory) and XML input as > optional. This will allow us to build both "thin" readers as well as > "heavy duty" readers where the readers support XML also and may > include the middleware software. > =20 > Bud Biswas >=20 > Rob.Buck@intermec.com wrote: > Viewpoint from another hardware vendor:=20 > =20 > If SLRRP gains traction we'll probably want to adapt it to a > reader module > with a serial interface to maintain a common interface between > readers. > However, if SLRRP is XML-based I don't think it will be viable > for serial > I/O. A minimal text protocol is marginal over serial. Adding > XML (even if > minimal) pushes the bandwidth over the top. > =20 > I agree with the human readable arguments of text vs binary. > With text > we've experienced lower training and support costs, faster > time-to-market, > etc. However, I foresee RFID development becoming more > specialized with the > proliferation of readers in the supply chain. It's likely that > vertical > application developers will only concern themselves with a > high-level > ALE-like interface. RFID middleware developers will grapple > with the > low-level interfaces. We have a! group of network programmers > that tell me > they prefer a binary interface. They have tools (LAN > analyzers, etc.) to > work with binary so they're not concerned with human readable. > They argue > that programming to a binary interface is easier/higher > performance than > parsing text. > =20 > Rob Buck > RFID Software Architect > Intermec Technologies, Corp. > Ofc: 641-472-3082 > Cell: 319-573-5294 > =20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org > [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Saturday, July 23, 2005 8:15 AM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: Re: [Rfid] XML vs. Text vs. Binary > =20 > =20 > Hi Marshall, > =20 > I think we are mostly in agreement about the technical > trade-offs,=20 > but for some reason that doesn't lead us to the same > conclusion... > =20 > At 9:16 AM +0530 7/23/05, Marshall Rose wrote: > >this brings us back full circle: as soon as you have any > level of=20 > >nesting, human! type-in becomes problematic. as soon as you > decide=20 > >that human type-in isn't mandatory, it is trivial to include > a=20 > >standard library to do the heavy lifting while the humans > invoke the=20 > >tool using textual commands. > =20 > Yes, if there is any significant nesting, I agree that a human > will=20 > not be able to type the commands in from memory and/or by > glancing at=20 > a reference sheet. However, I don't see any reason why this > protocol=20 > would require significant nesting, at least for the types of > commands=20 > that a human is likely to use directly. > =20 > With a text encoding, a human could also have certain prepared > commands and be able to cut and paste them into the interface > -- a=20 > command to reset autonomous operation, for example, or to set > a=20 > reader to its default state. Or they could write simple > scripts that=20 > would send specific commands or command sequences. > =20 > >in other words, from where i sit, XML, cXML, etc., enjoy all > the=20 > >drawbacks of both purist approaches. > =20 > Correct, from a "human typing" standpoint, XML, cXML and a=20 > specialized text encoding are all roughly equivalent. However, > in my=20 > opinion, they are all much better than a binary encoding. > =20 > There are two factors involved here, and all three of these > choices=20 > (XML, binary or specialized encodings) are fundamentally > different=20 > WRT these factors: > =20 > (1) Can the incoming stream be parsed by a widely available > parser,=20 > or is a specialized parser necessary. XML parsers are > available for=20 > all likely client systems, but a specialized text encoding or > a=20 > binary encoding would require a specialized parser. BTW, > subsetting=20 > XML _does not_ require a specialized parser. Reader vendors > might=20 > want to includes a specialized (smaller or faster) parser and > simply=20 > reject XML constructs that are not included in the subset, but > clients could use a regular XML parser for this purpose. > =20 > (2) Can ! text processing tools be used to send control > messages and=20 > interpret the responses, or would binary processing be > required.=20 > Both XML and a specialized text encoding would allow text > processing=20 > of the messages and results, while a binary encoding would > require=20 > binary processing. > =20 > You've indicated that it is possible, with a binary encoding, > for=20 > clients to run a tool that gives them text-based access. > That's=20 > true, but users would need to _get_ that tool from > somewhere... So,=20 > we are back to requiring specialized code on the client side > to=20 > access this protocol. > =20 > This isn't a religious issue with me -- I've just learned the=20 > benefits of text-based encoding the hard way, and I don't want > to=20 > deal with another binary protocol... So, for the moment, we > may have=20 > to just agree to disagree. We'd obviously need to resolve this > before we can move ahead, though. > =20 > Only a few of us have expressed any opinion on this subject. > Are there others out there that have an opinion? There are two > questions=20 > that I'd especially like to hear answered by specific other > people on=20 > this list: > =20 > (1) I'd like to hear from other reader vendors about whether > they=20 > think that XML would place a prohibitive burden on their > readers. It=20 > has been asserted that XML would have prohibitive system > requirements=20 > for the reader. That certainly isn't true of ThingMagic's > networked=20 > readers. In fact, using a standard parser, like XML, would > reduce=20 > our development (especially debugging) and testing costs=20 > substantially, and would make it more likely that we would > implement=20 > this protocol. > =20 > (2) It would be very interesting to know if RFID users would > see any=20 > benefit to a text-based encoding. Are there folks on this list > who=20 > have RFID installed in real-world or even pilot installations > (not=20 > just a few units in a test lab)? Do you have any opinions > about=20 > whether the ability to access t! he reader using text-based > tools from=20 > a client system that doesn't have a specialized client (or > library)=20 > installed would be useful? Or do you see this as having > little/no=20 > value? > =20 > Margaret > =20 > =20 > =20 > =20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > "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 > =20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid >=20 >=20 > Polaris Networks > your source for rfid test tools >=20 > ______________________________________________________________________ > _______________________________________________ > 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 _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid ------_=_NextPart_001_01C5982D.CFB2FFF9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Rfid] XML vs. Text vs. Binary

Howard,

I keep pointing to the proposed charter from the BoF, the subsequent = update, and the early SLRRP drafts as the set of motivations and goals = for the effort.  That is what was published and used to establish = the initial interest, and, based on advice from experienced IETFers, = frame a scope for a WG that could provide an initial standard = development success in an area that needs a standard.

Questions continue about the existence of goals and requirements.  = Are there specific things in the proposed charter that need to be = discussed?  If so we should do that.  Or, are we looking to = answer a question such as the XML vs. binary question by pointing to a = line that is or is not yet in the charter? 

Scott


-----Original Message-----
From: rfid-bounces@lists.ietf.org on behalf of Howard Kapustein
Sent: Wed 8/3/2005 12:37 AM
To: rfid@ietf.org
Subject: RE: [Rfid] XML vs. Text vs. Binary

>The base goals to date have been to focus on
>a single representation that would have the widest applicability = so
that
The hard part is defining 'one' syntax which is widely acceptable.
On good days it seems eminently reasonable and do-able.
On others...one wonders how hard herding cats really is...

>a standard could be developed and deployed as quickly as = possible.
Admirable goal.
Of course, this has to balance against the other targets - how'd = that
go? Fast, Small, Cheap, Quality, Durability, Quick to do, Easy to use = --
which are more (or less) important, and to what degree?


Are the goals, constraints and assumptions underlying the solution
called SLRRP clearly documented? Where? This seems to be a critical
linchpin for many of these differences of opinion -- some are
subjective, but lacking a clearly and commonly understood set of
requirements seems to be at the heart of many of these discussions. = XML
vs. Binary (among other things) can be argued ad nauseum to no end, = and
everyone is right *and* wrong. But given a clearly documented set of
requirements, people may disagree over priorities of the facts, but = the
facts remain.

Wouldn't solve all these debates, but would bring a measure of = rational
and objective measurement.

        - Howard



-----Original Message-----
From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.iet= f.org]
On Behalf Of Scott Barvick
Sent: Tuesday, August 02, 2005 5:25 PM
To: bbiswas@polarisnetworks.net
Cc: rfid@ietf.org; Rob.Buck@intermec.com
Subject: RE: [Rfid] XML vs. Text vs. Binary

Rob and Bud raise a topic that has not yet been fully addressed in = the
midst of this discussion - the notion of multiple representations of = the
protocol.  

This is even different from the carrying the PDUs over multiple
transports (e.g. TCP, serial, ethernet).  As raised in a = previous
thread, the concept of supporting transport of SLRRP PDUs over a = non-TCP
(serial) transport, while not currently in the initial SLRRP scope, = does
not seem to pose a significant burden in terms of specifying,
implementing, or testing.  All of the differences are isolated in = the
transport, and the same core protocol code is executed regardless of = how
you transport the PDUs to a particular peer.  

However, the idea of specifying different encodings (profiles),
particularly in the case of human readable vs. binary is something = that
I feel would not result in an efficient standard nor an efficient
standard development experience.  You end up with not a single = protocol,
but as many protocols as you have representations, and the only = thing
common about them may be an initial capabilities exchange.  = Each
representation then needs the full round of functional, system, and
interoperability testing that would go with any new protocol.  = Of
course, interoperability in this sense means only between
implementations of the same encoding, not implicitly for the all
encodings of the protocol.  The base goals to date have been to = focus on
a single representation that would have the widest applicability so = that
a standard could be developed and deployed as quickly as possible.

My thoughts only, of course.  I'm sure there are others out = there.

Scott 


On Tue, 2005-08-02 at 15:50, Bud Biswas wrote:
> I see the usefullness of both XML and binary to different = vendors.
> Altho' it is true that programmers will generally prefer binary = to
> work with, XML is also useful to a different user community = (non
> programmers). My preference would be to see that Readers = support
> binary as mandatory and XML as optional along with the = Middleware
> supports binary as input from reader (mandatory) and XML input = as
> optional. This will allow us to build both "thin" readers = as well as
> "heavy duty" readers where the readers support XML also = and may
> include the middleware software.
> 
> Bud Biswas
>
> Rob.Buck@intermec.com wrote:
>         Viewpoint from = another hardware vendor:
>        
>         If SLRRP gains = traction we'll probably want to adapt it to a
>         reader module
>         with a serial = interface to maintain a common interface between
>         readers.
>         However, if SLRRP = is XML-based I don't think it will be viable
>         for serial
>         I/O. A minimal text = protocol is marginal over serial. Adding
>         XML (even if
>         minimal) pushes the = bandwidth over the top.
>        
>         I agree with the = human readable arguments of text vs binary.
>         With text
>         we've experienced = lower training and support costs, faster
>         time-to-market,
>         etc. However, I = foresee RFID development becoming more
>         specialized with = the
>         proliferation of = readers in the supply chain. It's likely that
>         vertical
>         application = developers will only concern themselves with a
>         high-level
>         ALE-like interface. = RFID middleware developers will grapple
>         with the
>         low-level = interfaces. We have a! group of network programmers
>         that tell me
>         they prefer a = binary interface. They have tools (LAN
>         analyzers, etc.) = to
>         work with binary so = they're not concerned with human readable.
>         They argue
>         that programming to = a binary interface is easier/higher
>         performance = than
>         parsing text.
>        
>         Rob Buck
>         RFID Software = Architect
>         Intermec = Technologies, Corp.
>         Ofc: = 641-472-3082
>         Cell: = 319-573-5294
>        
>         -----Original = Message-----
>         From: = rfid-bounces@lists.ietf.org
>         [mailto:rfid-bounces@lists.iet= f.org] On
>         Behalf Of Margaret = Wasserman
>         Sent: Saturday, = July 23, 2005 8:15 AM
>         To: Marshall = Rose
>         Cc: = rfid@ietf.org
>         Subject: Re: [Rfid] = XML vs. Text vs. Binary
>        
>        
>         Hi Marshall,
>        
>         I think we are = mostly in agreement about the technical
>         trade-offs,
>         but for some reason = that doesn't lead us to the same
>         conclusion...
>        
>         At 9:16 AM +0530 = 7/23/05, Marshall Rose wrote:
>         >this brings us = back full circle: as soon as you have any
>         level of
>         >nesting, human! = type-in becomes problematic. as soon as you
>         decide
>         >that human = type-in isn't mandatory, it is trivial to include
>         a
>         >standard = library to do the heavy lifting while the humans
>         invoke the
>         >tool using = textual commands.
>        
>         Yes, if there is = any significant nesting, I agree that a human
>         will
>         not be able to type = the commands in from memory and/or by
>         glancing at
>         a reference sheet. = However, I don't see any reason why this
>         protocol
>         would require = significant nesting, at least for the types of
>         commands
>         that a human is = likely to use directly.
>        
>         With a text = encoding, a human could also have certain prepared
>         commands and be = able to cut and paste them into the interface
>         -- a
>         command to reset = autonomous operation, for example, or to set
>         a
>         reader to its = default state. Or they could write simple
>         scripts that
>         would send specific = commands or command sequences.
>        
>         >in other words, = from where i sit, XML, cXML, etc., enjoy all
>         the
>         >drawbacks of = both purist approaches.
>        
>         Correct, from a = "human typing" standpoint, XML, cXML and a
>         specialized text = encoding are all roughly equivalent. However,
>         in my
>         opinion, they are = all much better than a binary encoding.
>        
>         There are two = factors involved here, and all three of these
>         choices
>         (XML, binary or = specialized encodings) are fundamentally
>         different
>         WRT these = factors:
>        
>         (1) Can the = incoming stream be parsed by a widely available
>         parser,
>         or is a specialized = parser necessary. XML parsers are
>         available for
>         all likely client = systems, but a specialized text encoding or
>         a
>         binary encoding = would require a specialized parser. BTW,
>         subsetting
>         XML _does not_ = require a specialized parser. Reader vendors
>         might
>         want to includes a = specialized (smaller or faster) parser and
>         simply
>         reject XML = constructs that are not included in the subset, but
>         clients could use a = regular XML parser for this purpose.
>        
>         (2) Can ! text = processing tools be used to send control
>         messages and
>         interpret the = responses, or would binary processing be
>         required.
>         Both XML and a = specialized text encoding would allow text
>         processing
>         of the messages and = results, while a binary encoding would
>         require
>         binary = processing.
>        
>         You've indicated = that it is possible, with a binary encoding,
>         for
>         clients to run a = tool that gives them text-based access.
>         That's
>         true, but users = would need to _get_ that tool from
>         somewhere... = So,
>         we are back to = requiring specialized code on the client side
>         to
>         access this = protocol.
>        
>         This isn't a = religious issue with me -- I've just learned the
>         benefits of = text-based encoding the hard way, and I don't want
>         to
>         deal with another = binary protocol... So, for the moment, we
>         may have
>         to just agree to = disagree. We'd obviously need to resolve this
>         before we can move = ahead, though.
>        
>         Only a few of us = have expressed any opinion on this subject.
>         Are there others = out there that have an opinion? There are two
>         questions
>         that I'd especially = like to hear answered by specific other
>         people on
>         this list:
>        
>         (1) I'd like to = hear from other reader vendors about whether
>         they
>         think that XML = would place a prohibitive burden on their
>         readers. It
>         has been asserted = that XML would have prohibitive system
>         requirements
>         for the reader. = That certainly isn't true of ThingMagic's
>         networked
>         readers. In fact, = using a standard parser, like XML, would
>         reduce
>         our development = (especially debugging) and testing costs
>         substantially, and = would make it more likely that we would
>         implement
>         this protocol.
>        
>         (2) It would be = very interesting to know if RFID users would
>         see any
>         benefit to a = text-based encoding. Are there folks on this list
>         who
>         have RFID installed = in real-world or even pilot installations
>         (not
>         just a few units in = a test lab)? Do you have any opinions
>         about
>         whether the ability = to access t! he reader using text-based
>         tools from
>         a client system = that doesn't have a specialized client (or
>         library)
>         installed would be = useful? Or do you see this as having
>         little/no
>         value?
>        
>         Margaret
>        
>        
>        
>        
>         = _______________________________________________
>         Rfid mailing = list
>         = Rfid@lists.ietf.org
>         https://www1.ietf.or= g/mailman/listinfo/rfid
>         "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.or= g/mailman/listinfo/rfid
>
>
> Polaris Networks
> your source for rfid test tools
>
> = ______________________________________________________________________ > _______________________________________________
> Rfid mailing list
> Rfid@lists.ietf.org
> https://www1.ietf.or= g/mailman/listinfo/rfid


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

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

------_=_NextPart_001_01C5982D.CFB2FFF9-- --===============1866153457== 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 --===============1866153457==-- From rfid-bounces@lists.ietf.org Wed Aug 03 10:26:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KCJ-0001Xx-J0; Wed, 03 Aug 2005 10:26:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KCG-0001XK-R9 for rfid@megatron.ietf.org; Wed, 03 Aug 2005 10:26:17 -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 KAA21518 for ; Wed, 3 Aug 2005 10:26:14 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kix-0003x4-Q4 for rfid@ietf.org; Wed, 03 Aug 2005 11:00:04 -0400 Received: from ([10.100.101.65]) by relay3.manh.com with ESMTP id 4029073.8283390; Wed, 03 Aug 2005 10:25:23 -0400 Received: from ma-atl97.us.manh.com ([10.100.101.97]) by ma-atl63 with trend_isnt_name_B; Wed, 03 Aug 2005 10:25:22 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl97.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 10:25:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Wed, 3 Aug 2005 10:25:22 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEDF5@ma-atl57.us.manh.com> Thread-Topic: [Rfid] XML vs. Text vs. Binary Thread-Index: AcWXqPmdYiKHDcbzSa6g4sEfo9xmbAAOuPmgABF8wNIAAygIQgAAHAKg From: "Howard Kapustein" To: X-OriginalArrivalTime: 03 Aug 2005 14:25:22.0437 (UTC) FILETIME=[2EB82350:01C59837] X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org I'm not familiar with IETF policy and practice. If the "requirements" are scattered across multiple docs, that probably is a bad thing - hard to point to "the" unified requirements, and hard to expect such "simple" details to be clearly and readily grasped by all. >From recent traffic it seems there's even disagreement over the requirements and goals. That's the critical issue -- the binary v. xml technical wrangling is minor, if there's significant disagreement over the target. *Especially* given this, a single unified, clearly defined set of goals and requirements is needed IMO. At least then everyone can move the discussions to where they really belong, wrangling over the validity and priority of the requirements, and not indirectly beating on that thru the technical solution dialogues. Iron that out, and most of the subjective debate goes away - people may disagree over the requirements, but whether or not a specific solution meets their final agreed form is far more objective. - howard -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Scott Barvick To: Howard Kapustein ; rfid@ietf.org Sent: Wed Aug 03 09:18:17 2005 Subject: RE: [Rfid] XML vs. Text vs. Binary Howard, I keep pointing to the proposed charter from the BoF, the subsequent update, and the early SLRRP drafts as the set of motivations and goals for the effort. That is what was published and used to establish the initial interest, and, based on advice from experienced IETFers, frame a scope for a WG that could provide an initial standard development success in an area that needs a standard. Questions continue about the existence of goals and requirements. Are there specific things in the proposed charter that need to be discussed? If so we should do that. Or, are we looking to answer a question such as the XML vs. binary question by pointing to a line that is or is not yet in the charter?=20 Scott -----Original Message----- From: rfid-bounces@lists.ietf.org on behalf of Howard Kapustein Sent: Wed 8/3/2005 12:37 AM To: rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary >The base goals to date have been to focus on >a single representation that would have the widest applicability so that The hard part is defining 'one' syntax which is widely acceptable. On good days it seems eminently reasonable and do-able. On others...one wonders how hard herding cats really is... >a standard could be developed and deployed as quickly as possible. Admirable goal. Of course, this has to balance against the other targets - how'd that go? Fast, Small, Cheap, Quality, Durability, Quick to do, Easy to use -- which are more (or less) important, and to what degree? Are the goals, constraints and assumptions underlying the solution called SLRRP clearly documented? Where? This seems to be a critical linchpin for many of these differences of opinion -- some are subjective, but lacking a clearly and commonly understood set of requirements seems to be at the heart of many of these discussions. XML vs. Binary (among other things) can be argued ad nauseum to no end, and everyone is right *and* wrong. But given a clearly documented set of requirements, people may disagree over priorities of the facts, but the facts remain. Wouldn't solve all these debates, but would bring a measure of rational and objective measurement. - Howard -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Scott Barvick Sent: Tuesday, August 02, 2005 5:25 PM To: bbiswas@polarisnetworks.net Cc: rfid@ietf.org; Rob.Buck@intermec.com Subject: RE: [Rfid] XML vs. Text vs. Binary Rob and Bud raise a topic that has not yet been fully addressed in the midst of this discussion - the notion of multiple representations of the protocol. =20 This is even different from the carrying the PDUs over multiple transports (e.g. TCP, serial, ethernet). As raised in a previous thread, the concept of supporting transport of SLRRP PDUs over a non-TCP (serial) transport, while not currently in the initial SLRRP scope, does not seem to pose a significant burden in terms of specifying, implementing, or testing. All of the differences are isolated in the transport, and the same core protocol code is executed regardless of how you transport the PDUs to a particular peer. =20 However, the idea of specifying different encodings (profiles), particularly in the case of human readable vs. binary is something that I feel would not result in an efficient standard nor an efficient standard development experience. You end up with not a single protocol, but as many protocols as you have representations, and the only thing common about them may be an initial capabilities exchange. Each representation then needs the full round of functional, system, and interoperability testing that would go with any new protocol. Of course, interoperability in this sense means only between implementations of the same encoding, not implicitly for the all encodings of the protocol. The base goals to date have been to focus on a single representation that would have the widest applicability so that a standard could be developed and deployed as quickly as possible. My thoughts only, of course. I'm sure there are others out there. Scott=20 On Tue, 2005-08-02 at 15:50, Bud Biswas wrote: > I see the usefullness of both XML and binary to different vendors. > Altho' it is true that programmers will generally prefer binary to > work with, XML is also useful to a different user community (non > programmers). My preference would be to see that Readers support > binary as mandatory and XML as optional along with the Middleware > supports binary as input from reader (mandatory) and XML input as > optional. This will allow us to build both "thin" readers as well as > "heavy duty" readers where the readers support XML also and may > include the middleware software. >=20 > Bud Biswas > > Rob.Buck@intermec.com wrote: > Viewpoint from another hardware vendor: > =20 > If SLRRP gains traction we'll probably want to adapt it to a > reader module > with a serial interface to maintain a common interface between > readers. > However, if SLRRP is XML-based I don't think it will be viable > for serial > I/O. A minimal text protocol is marginal over serial. Adding > XML (even if > minimal) pushes the bandwidth over the top. > =20 > I agree with the human readable arguments of text vs binary. > With text > we've experienced lower training and support costs, faster > time-to-market, > etc. However, I foresee RFID development becoming more > specialized with the > proliferation of readers in the supply chain. It's likely that > vertical > application developers will only concern themselves with a > high-level > ALE-like interface. RFID middleware developers will grapple > with the > low-level interfaces. We have a! group of network programmers > that tell me > they prefer a binary interface. They have tools (LAN > analyzers, etc.) to > work with binary so they're not concerned with human readable. > They argue > that programming to a binary interface is easier/higher > performance than > parsing text. > =20 > Rob Buck > RFID Software Architect > Intermec Technologies, Corp. > Ofc: 641-472-3082 > Cell: 319-573-5294 > =20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org > [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Saturday, July 23, 2005 8:15 AM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: Re: [Rfid] XML vs. Text vs. Binary > =20 > =20 > Hi Marshall, > =20 > I think we are mostly in agreement about the technical > trade-offs, > but for some reason that doesn't lead us to the same > conclusion... > =20 > At 9:16 AM +0530 7/23/05, Marshall Rose wrote: > >this brings us back full circle: as soon as you have any > level of > >nesting, human! type-in becomes problematic. as soon as you > decide > >that human type-in isn't mandatory, it is trivial to include > a > >standard library to do the heavy lifting while the humans > invoke the > >tool using textual commands. > =20 > Yes, if there is any significant nesting, I agree that a human > will > not be able to type the commands in from memory and/or by > glancing at > a reference sheet. However, I don't see any reason why this > protocol > would require significant nesting, at least for the types of > commands > that a human is likely to use directly. > =20 > With a text encoding, a human could also have certain prepared > commands and be able to cut and paste them into the interface > -- a > command to reset autonomous operation, for example, or to set > a > reader to its default state. Or they could write simple > scripts that > would send specific commands or command sequences. > =20 > >in other words, from where i sit, XML, cXML, etc., enjoy all > the > >drawbacks of both purist approaches. > =20 > Correct, from a "human typing" standpoint, XML, cXML and a > specialized text encoding are all roughly equivalent. However, > in my > opinion, they are all much better than a binary encoding. > =20 > There are two factors involved here, and all three of these > choices > (XML, binary or specialized encodings) are fundamentally > different > WRT these factors: > =20 > (1) Can the incoming stream be parsed by a widely available > parser, > or is a specialized parser necessary. XML parsers are > available for > all likely client systems, but a specialized text encoding or > a > binary encoding would require a specialized parser. BTW, > subsetting > XML _does not_ require a specialized parser. Reader vendors > might > want to includes a specialized (smaller or faster) parser and > simply > reject XML constructs that are not included in the subset, but > clients could use a regular XML parser for this purpose. > =20 > (2) Can ! text processing tools be used to send control > messages and > interpret the responses, or would binary processing be > required. > Both XML and a specialized text encoding would allow text > processing > of the messages and results, while a binary encoding would > require > binary processing. > =20 > You've indicated that it is possible, with a binary encoding, > for > clients to run a tool that gives them text-based access. > That's > true, but users would need to _get_ that tool from > somewhere... So, > we are back to requiring specialized code on the client side > to > access this protocol. > =20 > This isn't a religious issue with me -- I've just learned the > benefits of text-based encoding the hard way, and I don't want > to > deal with another binary protocol... So, for the moment, we > may have > to just agree to disagree. We'd obviously need to resolve this > before we can move ahead, though. > =20 > Only a few of us have expressed any opinion on this subject. > Are there others out there that have an opinion? There are two > questions > that I'd especially like to hear answered by specific other > people on > this list: > =20 > (1) I'd like to hear from other reader vendors about whether > they > think that XML would place a prohibitive burden on their > readers. It > has been asserted that XML would have prohibitive system > requirements > for the reader. That certainly isn't true of ThingMagic's > networked > readers. In fact, using a standard parser, like XML, would > reduce > our development (especially debugging) and testing costs > substantially, and would make it more likely that we would > implement > this protocol. > =20 > (2) It would be very interesting to know if RFID users would > see any > benefit to a text-based encoding. Are there folks on this list > who > have RFID installed in real-world or even pilot installations > (not > just a few units in a test lab)? Do you have any opinions > about > whether the ability to access t! he reader using text-based > tools from > a client system that doesn't have a specialized client (or > library) > installed would be useful? Or do you see this as having > little/no > value? > =20 > Margaret > =20 > =20 > =20 > =20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > "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 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > > > Polaris Networks > your source for rfid test tools > > ______________________________________________________________________ > _______________________________________________ > 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 _______________________________________________ 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 Aug 03 10:35:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KLW-000860-0E; Wed, 03 Aug 2005 10:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KLT-00084w-V9 for rfid@megatron.ietf.org; Wed, 03 Aug 2005 10:35:47 -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 KAA22274 for ; Wed, 3 Aug 2005 10:35:46 -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.43) id 1E0KsB-0004Oq-6b for rfid@ietf.org; Wed, 03 Aug 2005 11:09:35 -0400 Received: by normail.norand.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Aug 2005 09:35:57 -0500 Message-ID: <49E558014BABD711AA980002A5421C999E04F3@normail.norand.com> To: rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Wed, 3 Aug 2005 09:35:55 -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: 8cb9b411340046bf4080a729180a0672 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org It's a hard pill to swallow, but I'm lining up in agreement with Scott: the standard is gonna have to come down to one encoding to be effective. Rob -----Original Message----- From: Scott Barvick [mailto:sbarvick@revasystems.com] Sent: Tuesday, August 02, 2005 4:25 PM To: bbiswas@polarisnetworks.net Cc: Rob.Buck@intermec.com; rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary Rob and Bud raise a topic that has not yet been fully addressed in the midst of this discussion - the notion of multiple representations of the protocol. This is even different from the carrying the PDUs over multiple transports (e.g. TCP, serial, ethernet). As raised in a previous thread, the concept of supporting transport of SLRRP PDUs over a non-TCP (serial) transport, while not currently in the initial SLRRP scope, does not seem to pose a significant burden in terms of specifying, implementing, or testing. All of the differences are isolated in the transport, and the same core protocol code is executed regardless of how you transport the PDUs to a particular peer. However, the idea of specifying different encodings (profiles), particularly in the case of human readable vs. binary is something that I feel would not result in an efficient standard nor an efficient standard development experience. You end up with not a single protocol, but as many protocols as you have representations, and the only thing common about them may be an initial capabilities exchange. Each representation then needs the full round of functional, system, and interoperability testing that would go with any new protocol. Of course, interoperability in this sense means only between implementations of the same encoding, not implicitly for the all encodings of the protocol. The base goals to date have been to focus on a single representation that would have the widest applicability so that a standard could be developed and deployed as quickly as possible. My thoughts only, of course. I'm sure there are others out there. Scott On Tue, 2005-08-02 at 15:50, Bud Biswas wrote: > I see the usefullness of both XML and binary to different vendors. > Altho' it is true that programmers will generally prefer binary to > work with, XML is also useful to a different user community (non > programmers). My preference would be to see that Readers support > binary as mandatory and XML as optional along with the Middleware > supports binary as input from reader (mandatory) and XML input as > optional. This will allow us to build both "thin" readers as well as > "heavy duty" readers where the readers support XML also and may > include the middleware software. > > Bud Biswas > > Rob.Buck@intermec.com wrote: > Viewpoint from another hardware vendor: > > If SLRRP gains traction we'll probably want to adapt it to a > reader module > with a serial interface to maintain a common interface between > readers. > However, if SLRRP is XML-based I don't think it will be viable > for serial > I/O. A minimal text protocol is marginal over serial. Adding > XML (even if > minimal) pushes the bandwidth over the top. > > I agree with the human readable arguments of text vs binary. > With text > we've experienced lower training and support costs, faster > time-to-market, > etc. However, I foresee RFID development becoming more > specialized with the > proliferation of readers in the supply chain. It's likely that > vertical > application developers will only concern themselves with a > high-level > ALE-like interface. RFID middleware developers will grapple > with the > low-level interfaces. We have a! group of network programmers > that tell me > they prefer a binary interface. They have tools (LAN > analyzers, etc.) to > work with binary so they're not concerned with human readable. > They argue > that programming to a binary interface is easier/higher > performance than > parsing text. > > Rob Buck > RFID Software Architect > Intermec Technologies, Corp. > Ofc: 641-472-3082 > Cell: 319-573-5294 > > -----Original Message----- > From: rfid-bounces@lists.ietf.org > [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Saturday, July 23, 2005 8:15 AM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: Re: [Rfid] XML vs. Text vs. Binary > > > Hi Marshall, > > I think we are mostly in agreement about the technical > trade-offs, > but for some reason that doesn't lead us to the same > conclusion... > > At 9:16 AM +0530 7/23/05, Marshall Rose wrote: > >this brings us back full circle: as soon as you have any > level of > >nesting, human! type-in becomes problematic. as soon as you > decide > >that human type-in isn't mandatory, it is trivial to include > a > >standard library to do the heavy lifting while the humans > invoke the > >tool using textual commands. > > Yes, if there is any significant nesting, I agree that a human > will > not be able to type the commands in from memory and/or by > glancing at > a reference sheet. However, I don't see any reason why this > protocol > would require significant nesting, at least for the types of > commands > that a human is likely to use directly. > > With a text encoding, a human could also have certain prepared > commands and be able to cut and paste them into the interface > -- a > command to reset autonomous operation, for example, or to set > a > reader to its default state. Or they could write simple > scripts that > would send specific commands or command sequences. > > >in other words, from where i sit, XML, cXML, etc., enjoy all > the > >drawbacks of both purist approaches. > > Correct, from a "human typing" standpoint, XML, cXML and a > specialized text encoding are all roughly equivalent. However, > in my > opinion, they are all much better than a binary encoding. > > There are two factors involved here, and all three of these > choices > (XML, binary or specialized encodings) are fundamentally > different > WRT these factors: > > (1) Can the incoming stream be parsed by a widely available > parser, > or is a specialized parser necessary. XML parsers are > available for > all likely client systems, but a specialized text encoding or > a > binary encoding would require a specialized parser. BTW, > subsetting > XML _does not_ require a specialized parser. Reader vendors > might > want to includes a specialized (smaller or faster) parser and > simply > reject XML constructs that are not included in the subset, but > clients could use a regular XML parser for this purpose. > > (2) Can ! text processing tools be used to send control > messages and > interpret the responses, or would binary processing be > required. > Both XML and a specialized text encoding would allow text > processing > of the messages and results, while a binary encoding would > require > binary processing. > > You've indicated that it is possible, with a binary encoding, > for > clients to run a tool that gives them text-based access. > That's > true, but users would need to _get_ that tool from > somewhere... So, > we are back to requiring specialized code on the client side > to > access this protocol. > > This isn't a religious issue with me -- I've just learned the > benefits of text-based encoding the hard way, and I don't want > to > deal with another binary protocol... So, for the moment, we > may have > to just agree to disagree. We'd obviously need to resolve this > before we can move ahead, though. > > Only a few of us have expressed any opinion on this subject. > Are there others out there that have an opinion? There are two > questions > that I'd especially like to hear answered by specific other > people on > this list: > > (1) I'd like to hear from other reader vendors about whether > they > think that XML would place a prohibitive burden on their > readers. It > has been asserted that XML would have prohibitive system > requirements > for the reader. That certainly isn't true of ThingMagic's > networked > readers. In fact, using a standard parser, like XML, would > reduce > our development (especially debugging) and testing costs > substantially, and would make it more likely that we would > implement > this protocol. > > (2) It would be very interesting to know if RFID users would > see any > benefit to a text-based encoding. Are there folks on this list > who > have RFID installed in real-world or even pilot installations > (not > just a few units in a test lab)? Do you have any opinions > about > whether the ability to access t! he reader using text-based > tools from > a client system that doesn't have a specialized client (or > library) > installed would be useful? Or do you see this as having > little/no > value? > > Margaret > > > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > "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 > > > Polaris Networks > your source for rfid test tools > > ______________________________________________________________________ > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid "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 Wed Aug 03 12:40:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MHv-0006Gs-1V; Wed, 03 Aug 2005 12:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MHt-0006E8-5h for rfid@megatron.ietf.org; Wed, 03 Aug 2005 12:40: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 MAA29847 for ; Wed, 3 Aug 2005 12:40:10 -0400 (EDT) Received: from mail.intelleflex.com ([66.236.103.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MoY-0001FQ-TZ for rfid@ietf.org; Wed, 03 Aug 2005 13:14:01 -0400 Received: from SureshLaptopIF (SureshLaptopIF.intelleflex.com [10.1.7.166]) by mail.intelleflex.com (8.13.3/8.13.3) with ESMTP id j73Gdwhe014500; Wed, 3 Aug 2005 09:39:58 -0700 Message-Id: <200508031639.j73Gdwhe014500@mail.intelleflex.com> From: "Suresh Bhaskaran" To: , Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Wed, 3 Aug 2005 09:39:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcWYOP/4gr9SWN+DQt6aEeBLP3/JKAADrZCg In-Reply-To: <49E558014BABD711AA980002A5421C999E04F3@normail.norand.com> X-Scanned-By: MIMEDefang 2.49 on 10.1.7.25 X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org What attracted me (us) about SLRRP from the beginning are the following: You might say that it "met" certain requirements that were important to us: 1. A "minimal" "full" reader that is networked, and yet exposes enough air interface parameters to allow useful "RF subsystem management" at a multi-reader level a. by "full", I mean basic RFID functionality: read EPC numbers, read/write memory, etc., as well as the basic management functionality: e.g. set reader config, get reader info (e.g. status, health, etc.), as well as some basic asynchronous messages (e.g. Reader Status Report that is sent asynchronously). b. Multi-reader RF subsystem management is going to be (is already) a *very* important part of scalable RFID deployments 2. I liked the way the TLV's "tiled" together: very conceptually easy, clean, and easily extensible. 3. The fact that the "networking" part of it was standard: i.e. TCP/IP, can draw on existing TCP/IP security, and other internet technology 4. Also, it (meaning a low-level reader) can be abstracted to a higher level, if desired (e.g. ALE or portions thereof). It is much easier to go from a "low-level" abstraction to a higher-level. Much harder to do the other way around (since the important elements have already been abstracted away). 5. The read/modify/write timing (provided by the Access specs in SLRRP) is very attractive. The read/modify/write time is one of *the* critical timing requirements for an effective reader. We can't abstract away the "tightness" of this loop -- it directly affects overall read rate. 6. There is some thinking in the SLRRP spec about sensors and memory (very important future extensions RFID, it seems to me). 7. It has thought about scalability and discovery (although discovery may move to a separate topic, as might the "management" part?!). I like the "integrated" nature of SLRRP (i.e. *not* a separate standard for operational, and management, and discovery, etc. -- that "splinters" it, in my view). 8. Basic triggering, and filtering is included (not the type of filtering necessary at ALE level, but nonetheless, some *basic* filtering: e.g. eliminating duplicates, matching a set of EPC numbers, etc. (refer to the Access Spec of SLRRP). In Summary, I think the SLRRP is a *very well* thought out spec, at the "right level" that it needs to be. Hopefully, some of the points I shared could also serve as the basis of a "requirements", and a "charter focus" for SLRRP. SLRRP is an excellent balance beween "real-time", and "abstraction", and "networked" and "full reader" and "simple". Suresh Bhaskaran Intelleflex. -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Rob.Buck@intermec.com Sent: Wednesday, August 03, 2005 7:36 AM To: rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary It's a hard pill to swallow, but I'm lining up in agreement with Scott: the standard is gonna have to come down to one encoding to be effective. Rob -----Original Message----- From: Scott Barvick [mailto:sbarvick@revasystems.com] Sent: Tuesday, August 02, 2005 4:25 PM To: bbiswas@polarisnetworks.net Cc: Rob.Buck@intermec.com; rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary Rob and Bud raise a topic that has not yet been fully addressed in the midst of this discussion - the notion of multiple representations of the protocol. This is even different from the carrying the PDUs over multiple transports (e.g. TCP, serial, ethernet). As raised in a previous thread, the concept of supporting transport of SLRRP PDUs over a non-TCP (serial) transport, while not currently in the initial SLRRP scope, does not seem to pose a significant burden in terms of specifying, implementing, or testing. All of the differences are isolated in the transport, and the same core protocol code is executed regardless of how you transport the PDUs to a particular peer. However, the idea of specifying different encodings (profiles), particularly in the case of human readable vs. binary is something that I feel would not result in an efficient standard nor an efficient standard development experience. You end up with not a single protocol, but as many protocols as you have representations, and the only thing common about them may be an initial capabilities exchange. Each representation then needs the full round of functional, system, and interoperability testing that would go with any new protocol. Of course, interoperability in this sense means only between implementations of the same encoding, not implicitly for the all encodings of the protocol. The base goals to date have been to focus on a single representation that would have the widest applicability so that a standard could be developed and deployed as quickly as possible. My thoughts only, of course. I'm sure there are others out there. Scott On Tue, 2005-08-02 at 15:50, Bud Biswas wrote: > I see the usefullness of both XML and binary to different vendors. > Altho' it is true that programmers will generally prefer binary to > work with, XML is also useful to a different user community (non > programmers). My preference would be to see that Readers support > binary as mandatory and XML as optional along with the Middleware > supports binary as input from reader (mandatory) and XML input as > optional. This will allow us to build both "thin" readers as well as > "heavy duty" readers where the readers support XML also and may > include the middleware software. > > Bud Biswas > > Rob.Buck@intermec.com wrote: > Viewpoint from another hardware vendor: > > If SLRRP gains traction we'll probably want to adapt it to a > reader module > with a serial interface to maintain a common interface between > readers. > However, if SLRRP is XML-based I don't think it will be viable > for serial > I/O. A minimal text protocol is marginal over serial. Adding > XML (even if > minimal) pushes the bandwidth over the top. > > I agree with the human readable arguments of text vs binary. > With text > we've experienced lower training and support costs, faster > time-to-market, > etc. However, I foresee RFID development becoming more > specialized with the > proliferation of readers in the supply chain. It's likely that > vertical > application developers will only concern themselves with a > high-level > ALE-like interface. RFID middleware developers will grapple > with the > low-level interfaces. We have a! group of network programmers > that tell me > they prefer a binary interface. They have tools (LAN > analyzers, etc.) to > work with binary so they're not concerned with human readable. > They argue > that programming to a binary interface is easier/higher > performance than > parsing text. > > Rob Buck > RFID Software Architect > Intermec Technologies, Corp. > Ofc: 641-472-3082 > Cell: 319-573-5294 > > -----Original Message----- > From: rfid-bounces@lists.ietf.org > [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Saturday, July 23, 2005 8:15 AM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: Re: [Rfid] XML vs. Text vs. Binary > > > Hi Marshall, > > I think we are mostly in agreement about the technical > trade-offs, > but for some reason that doesn't lead us to the same > conclusion... > > At 9:16 AM +0530 7/23/05, Marshall Rose wrote: > >this brings us back full circle: as soon as you have any > level of > >nesting, human! type-in becomes problematic. as soon as you > decide > >that human type-in isn't mandatory, it is trivial to include > a > >standard library to do the heavy lifting while the humans > invoke the > >tool using textual commands. > > Yes, if there is any significant nesting, I agree that a human > will > not be able to type the commands in from memory and/or by > glancing at > a reference sheet. However, I don't see any reason why this > protocol > would require significant nesting, at least for the types of > commands > that a human is likely to use directly. > > With a text encoding, a human could also have certain prepared > commands and be able to cut and paste them into the interface > -- a > command to reset autonomous operation, for example, or to set > a > reader to its default state. Or they could write simple > scripts that > would send specific commands or command sequences. > > >in other words, from where i sit, XML, cXML, etc., enjoy all > the > >drawbacks of both purist approaches. > > Correct, from a "human typing" standpoint, XML, cXML and a > specialized text encoding are all roughly equivalent. However, > in my > opinion, they are all much better than a binary encoding. > > There are two factors involved here, and all three of these > choices > (XML, binary or specialized encodings) are fundamentally > different > WRT these factors: > > (1) Can the incoming stream be parsed by a widely available > parser, > or is a specialized parser necessary. XML parsers are > available for > all likely client systems, but a specialized text encoding or > a > binary encoding would require a specialized parser. BTW, > subsetting > XML _does not_ require a specialized parser. Reader vendors > might > want to includes a specialized (smaller or faster) parser and > simply > reject XML constructs that are not included in the subset, but > clients could use a regular XML parser for this purpose. > > (2) Can ! text processing tools be used to send control > messages and > interpret the responses, or would binary processing be > required. > Both XML and a specialized text encoding would allow text > processing > of the messages and results, while a binary encoding would > require > binary processing. > > You've indicated that it is possible, with a binary encoding, > for > clients to run a tool that gives them text-based access. > That's > true, but users would need to _get_ that tool from > somewhere... So, > we are back to requiring specialized code on the client side > to > access this protocol. > > This isn't a religious issue with me -- I've just learned the > benefits of text-based encoding the hard way, and I don't want > to > deal with another binary protocol... So, for the moment, we > may have > to just agree to disagree. We'd obviously need to resolve this > before we can move ahead, though. > > Only a few of us have expressed any opinion on this subject. > Are there others out there that have an opinion? There are two > questions > that I'd especially like to hear answered by specific other > people on > this list: > > (1) I'd like to hear from other reader vendors about whether > they > think that XML would place a prohibitive burden on their > readers. It > has been asserted that XML would have prohibitive system > requirements > for the reader. That certainly isn't true of ThingMagic's > networked > readers. In fact, using a standard parser, like XML, would > reduce > our development (especially debugging) and testing costs > substantially, and would make it more likely that we would > implement > this protocol. > > (2) It would be very interesting to know if RFID users would > see any > benefit to a text-based encoding. Are there folks on this list > who > have RFID installed in real-world or even pilot installations > (not > just a few units in a test lab)? Do you have any opinions > about > whether the ability to access t! he reader using text-based > tools from > a client system that doesn't have a specialized client (or > library) > installed would be useful? Or do you see this as having > little/no > value? > > Margaret > > > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > "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 > > > Polaris Networks > your source for rfid test tools > > ______________________________________________________________________ > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid "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 _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Tue Aug 16 10:07:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E526F-0004vM-Vs; Tue, 16 Aug 2005 10:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E526D-0004vH-V8 for rfid@megatron.ietf.org; Tue, 16 Aug 2005 10:07:30 -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 KAA12988 for ; Tue, 16 Aug 2005 10:07:27 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E52fY-00026q-IY for rfid@ietf.org; Tue, 16 Aug 2005 10:44:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Aug 2005 10:06:58 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16EBFF449@ms08.mse3.exchange.ms> Thread-Topic: Ver 03 of the draft Thread-Index: AcWia8QGrIOc23q3QKuaBRqB/RRKRw== From: "P. Krishna" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [Rfid] Ver 03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0134743919==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0134743919== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A26B.C412E958" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A26B.C412E958 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We have release 03 version of the draft. The link is as follows: http://www.ietf.org/internet-drafts/draft-krishna-slrrp-03.txt Changelist: - Vendor extension capability in commands - Explanation of use of Parameters in SLRRP - Op-specs: all op-specs now look consistent and have length field. - Creation of Tag Parameter and Tag Mask Parameter. - Creation of Trigger Parameter and Trigger Value Parameter. Specified = some triggers. - Inventory Operation Timing Parameter: now has Start Trigger and Stop = Trigger parameters. - Trigger Parameter in Inventory and Status Reporting Parameter - Tag Data Parameter: added Tag Seen Count (smoothing) and Frequency. - In the C1G2 singulation parameter: made the I and S fields as 2 bits. = It used to be 1 bit. This is to support usecases where the RNC may not = send the tag state bit to the reader; it rather depends on the reader = algorithms to track tag state during inventory. ---------------------------------- /Krishna =20 ------_=_NextPart_001_01C5A26B.C412E958 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=

Hi,

=0A=

We have release 03 version of the draft. = The link is =0A= as follows:

=0A=

h= ttp://www.ietf.org/internet-drafts/draft-krishna-slrrp-03.txt<= /P>=0A=

Changelist:

=0A=

- Vendor extension capability in commands
- = Explanation of =0A= use of Parameters in SLRRP
- Op-specs: all op-specs now look = consistent and =0A= have length field.
- Creation of Tag Parameter and Tag Mask = Parameter.
- =0A= Creation of Trigger Parameter and Trigger Value Parameter. Specified = some =0A= triggers.
- Inventory Operation Timing Parameter: now has Start = Trigger and =0A= Stop Trigger parameters.
- Trigger Parameter in Inventory and Status =0A= Reporting Parameter
- Tag Data Parameter: added Tag Seen Count = (smoothing) =0A= and Frequency.
- In the C1G2 singulation parameter: made the I and S = fields =0A= as 2 bits. It used to be 1 bit. This is to support usecases where the = RNC may =0A= not send the tag state bit to the reader; it rather depends on the = reader =0A= algorithms to track tag state during inventory.

=0A=

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

=0A=

/Krishna

 
------_=_NextPart_001_01C5A26B.C412E958-- --===============0134743919== 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 --===============0134743919==-- From rfid-bounces@lists.ietf.org Tue Aug 23 06:06:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7VfQ-0004WT-K4; Tue, 23 Aug 2005 06:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7VfP-0004WJ-2b for rfid@megatron.ietf.org; Tue, 23 Aug 2005 06:06:03 -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 GAA24201 for ; Tue, 23 Aug 2005 06:06:00 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7VfU-00074b-VD for rfid@ietf.org; Tue, 23 Aug 2005 06:06:09 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7NA5ffa027559; Tue, 23 Aug 2005 05:05:42 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Aug 2005 12:05:40 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507E0D931@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Scott Barvick (E-mail)" , "Marshall Rose (E-mail)" Date: Tue, 23 Aug 2005 12:05:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rfid@ietf.org, "David Kessens \(E-mail\)" Subject: [Rfid] CAIRO/SLRRP WG will not be formed 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org BOF Chairs and rfid mailing list subscribers, A "no decision" is better than no decision at all. The idea of chartering a CAIRO (formerly SLRRP) WG has been on the table for a while and was still lingering up till now. The OPS ADs have decided (with support from the IESG) to not charter this WG. Bert Wijnen and David Kessens, IETF OPS Area Directors --------- Background: The SLRRP BOF was held in the APPS Area in March. Later, the APPS & OPS ADs discussed this work and decided that there was a better fit with the OPS area and and that is why the OPS ADs have been taking the lead on the potential WG chartering. We have been unable to get enough support (at all, let alone in public) from the mayor players that they want to do this work in IETF as opposed to EPCGlobal. We did get a positive/public statement from ISO though (ISO/IEC JTC 1SC 31/WG 4/SG 1 Convener): https://datatracker.ietf.org/documents/LIAISON/file167.pdf But that is not enough to charter this work in IETF. Specicially EPCGlobal asked us to not charter the work as per: https://datatracker.ietf.org/documents/LIAISON/file148.txt and so without a clear sign from the major players that they do not agree with their EPCGlobal request, we have a tough time to charter it. Besides, we now hear that a small group in EPCGlobal (including some proponents of chartering the work in IETF) are working hard to try and see if this work can be done in EPCGlobal. All in all, this is just going on too long without people showing the interest and openly supporting the work in the IETF. If in the future anyone believes that a CAIRO like effort is needed in the IETF, then they will have to start from scratch and we'd strongly recommend they get people to line up behind the idea in public first. Bert and David _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Sat Aug 27 10:21:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yj-0000sr-2W; Sat, 27 Aug 2005 10:21:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yh-0000sF-NW for rfid@megatron.ietf.org; Sat, 27 Aug 2005 10:21:23 -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 KAA15726 for ; Sat, 27 Aug 2005 10:21:21 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E91Ze-0001by-IS for rfid@ietf.org; Sat, 27 Aug 2005 10:22:22 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7RELCS0007798 for ; Sat, 27 Aug 2005 09:21:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 27 Aug 2005 16:21:12 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507E0E393@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: rfid@ietf.org Date: Sat, 27 Aug 2005 16:21:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Rfid] CAIRO WG not charter, but mailing list stays open. 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org RFID subscribers, Sorry that it took a while before I could announce this. But I did check with IESG and secretariat first that it is ok to keep list rfid@ietf.org open and running even though we decided to not charter the CAIRO WG. You (as a community) can keep it for now. I have added it to the list of IETF Non-WG mailing lists at https://datatracker.ietf.org/public/nwg_list.cgi Hope this helps. Bert _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid