"Sri Gundavelli (sgundave)" <sgundave@xxxxxxxxx> 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.
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.
Dale