HI Dale,
Thanks again for the comments. Please see inline.
On 2/13/17, 8:55 AM, "Dale R. Worley" <worley(_at_)ariadne(_dot_)com> wrote:
"Sri Gundavelli (sgundave)" <sgundave(_at_)cisco(_dot_)com> writes:
When we discussed this issue in the past, the general feedback from
the WG was that the draft should provide some minimal amount of
details on the new identifier types, what the identifier is, how the
identifier is constructed, what is the access technology and a
reference to the specification that provides that definition. The idea
is NOT TO provide extensive details on the spec, but to enable a
reader with some high level details and a pointer to the
specification. I tend to think the text in the current specification
just does that. If the text is seen as redundant text, we can
certainly add a statement saying that the definition for the
identifier is provided in spec-XYZ and is repeated here for
convenience. May be other folks in the WG have some views on this.
I take it that the following are typical comments from the WG:
Comments from 10/11/2015 email:
"Some text on the motivation for defining new Types may be
helpful. Document is not just standardizing the currently
in-use/popular identifier types, its also introducing new types are
not in use. The reasons/interest for defining identifiers that are
tied to the physical elements of the device (RFID, MAC address ..etc)
and how it helps in deployment of the technology may be useful. Few
lines of text will really help."
"I was hoping to see a sub-section for each of the types. We cannot
standardize a identifier type without providing any explanation on the
identifier type or the references to the base definitions. This can be
painful, but I'd have a small section for each of the types. It can be
3 line text on the a.) Definition b.) Format c.) Example format d.)
Reference to the base spec that defines those identifiers."
I can understand these desires, and I agree with following them.
In regard to the first message, it seems to request "The
reasons/interest for defining identifiers that are tied to the physical
elements of the device (RFID, MAC address ..etc) and how it helps in
deployment of the technology may be useful." As far as I can tell, this
isn't handled in section 4.9 (which is the part I was complaining
about). And I don't recall if the earlier parts of the draft are
specific about "the reasons/interest" for any of the new types. I
believe from this discussion that the reason an identifier was included
is that somebody told the authors that they wanted to use the identifier
in question -- and that is quite legitimate. Perhaps saying it
explicitly in the early parts of the draft would help.
In regard to the second message, it seems to request
a small section for each of the types. It can be
3 line text on the
a.) Definition
b.) Format
c.) Example format
d.) Reference to the base spec that defines those identifiers.
Of course, (d) "reference to base spec" is necessary, and the
sub-sections of 4.9 do that for each format, as does Table 1.
For (a) "definition", the texts in 4.9 proper seem to be fairly good.
E.g.,
The EPC encoding scheme for SGTIN permits the direct embedding of
EAN.UCC System standard GTIN and Serial Number codes on EPC tags. In
all cases, the check digit is not encoded. Two encoding schemes are
specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits).
Based on that alone, I couldn't possibly construct a SGTIN-64 myself,
but I have some idea of the information it contains and the technical
terms to look up to find the real definition of the data items.
However (b) "format" seems to be missing (except in the most abstract
sense) and (c) "example format" seem to be missing entirely. OTOH, I'm
not sure that the space needed to specify those would be worth the
effort.
[Sri] I agree. The goal was to make the spec complete. What ever
identifiers we are carrying in this option, we provide the format,
structure and semantics of construction and not treat it like an opaque
container. But, its a delicate balance, not ending up with a lot of
duplicated text, vs incomplete specification. I agree, its not worth the
efforts doing a significant re-write. The current text is probably fine.
Summary: After thinking about it more, I think it's not worth the
effort to revise 4.9 heavily. Most of that information is for the use
of people who are familiar with the RFID identifiers and their formats,
and if they are happy with it, there's no reason to change it.
[Sri] I agree with your summary.
Dale