Comment Details - National Information Standards Organization

#00109 Comment Details - RP-6-201x_RFID-in_US_Libraries_rev_for_comment.pdf

Document Information
Title	NISO RP-6-201x, RFID in U.S. Libraries (Draft for Comment)
File Name	RP-6-201x_RFID-in_US_Libraries_rev_for_comment.pdf	State	Draft
Date Added	2011-05-09 15:22:54	Revision Number	0
Submitter Name	Cynthia Hodgson	Size	603K

Comment Information
Summary	Recommend that Tag Content Key be optional	State (Disposition)	New (Unresolved)
Date Added	2011-05-11 07:26:05	Last Updated	2011-05-11 07:26:06
Submitter Name	David Berquist	Assigned To	Unassigned
Company Name	3M Company	Response	None
Interest Category		Category	N/A
Origin	Public Review	Section, Page, Line	Section 2.5.3, Page 11
Item		Item Description

Submitter Comment
The Tag Content Key is most useful with large amounts of data. But with small amounts of data, it adds unacceptable overhead. Consider a "high performance" application such as a sorter that has "one chance" to read a tag as it passes by. This application will not be able to parse a Tag Content Key and read a second time so it needs to get all data in one read. The Tag Content Key increases the number of bytes that must be read in this "one read" which will affect performance (see example below). The ISO 28560-2 document lists Tag Content Key as optional and I recommend that NISO does also. Here is an simple example of encoding an item ID of 12345678901234 and Alternate Library ID of US1234 with/without Tag Content key. The Tag Content key increases the number of tag blocks (a block is 4 bytes) from 4 to 6. A block is the minimum number of bytes that can be read from a tag so this adds 50% to the amount of data that needs to be read. While this is a simple example, you can easily find other scenarios involving higher-numbered relative OIDs (I chose Alternate Library ID which has a relative OID of 23). Data without Tag Content key: 11060B3A 73CE2FF2 4F080555 3C72CF48 Data with Tag Content key: 11060B3A 73CE2FF2 02030000 084F0805 553C72CF 48000000

Submitter Comment

The Tag Content Key is most useful with large amounts of data. But with small amounts of data, it adds unacceptable overhead. Consider a "high performance" application such as a sorter that has "one chance" to read a tag as it passes by. This application will not be able to parse a Tag Content Key and read a second time so it needs to get all data in one read. The Tag Content Key increases the number of bytes that must be read in this "one read" which will affect performance (see example below).
The ISO 28560-2 document lists Tag Content Key as optional and I recommend that NISO does also.

Here is an simple example of encoding an item ID of 12345678901234 and Alternate Library ID of US1234 with/without Tag Content key. The Tag Content key increases the number of tag blocks (a block is 4 bytes) from 4 to 6. A block is the minimum number of bytes that can be read from a tag so this adds 50% to the amount of data that needs to be read. While this is a simple example, you can easily find other scenarios involving higher-numbered relative OIDs (I chose Alternate Library ID which has a relative OID of 23).
Data without Tag Content key:
11060B3A
73CE2FF2
4F080555
3C72CF48
Data with Tag Content key:
11060B3A
73CE2FF2
02030000
084F0805
553C72CF
48000000

Submitter Proposed Solution
Change Tag Content Key requirement to Optional or Strongly Recommended. Perhaps add text to explain how avoiding it helps with high performance applications.

Submitter Proposed Solution

Change Tag Content Key requirement to Optional or Strongly Recommended. Perhaps add text to explain how avoiding it helps with high performance applications.