Hello Dale,
O.K. I will take a crack at making this reorganization. If you have
text of course that will be appreciated. Right now I don't see why
anyone in the WG would object, but I hope at least some people will take
a look.
I can have the revised draft ready in a few days. I think this resolves
the last point of discussion that has been raised about the draft.
Regards,
Charlie P.
On 2/14/2017 5:04 PM, Dale R. Worley wrote:
Charlie Perkins <charles.perkins@xxxxxxxxxxxxx> writes:
I am hesitant to replace so many MNID types by a single URN type with
substructure. What would you think about replacing the existing
RFID-*-URI types with a single URN type, but leaving the existing binary
types? This gets the benefit you suggest for future extensibility, but
retains the shorter forms that may often be advantageous.
Suddenly today I realized something I should have realized in the
review, which would have saved us much time in discussion. Viz.,
consider this proposal:
- one MNID type for *all* the EPC binary schemes
- one MNID type for *all* URNs, *including* the EPC URI forms
This would work, since (1) (not surprisingly) the EPC binary schemes are
all differentiated by their first 8 bits. (see table on page 19 of the
tag-data standard,
http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf)
and (2) all URNs are differentiated by their namespace part.
(This parallels using one MNID number for all DUID types, since DUIDs
have an internal indicator for the four types.)
This approach has all the desirable properties anyone has mentioned so
far:
- includes all EPC binary and URI forms
- automatically includes all existing and future EPC binary forms
- automatically includes all existing and future URN forms *including*
all existing and future EPC URI forms
- doesn't have a proliferation of MNID type numbers which duplicate
information that can be fairly easily extracted from the
identifier itself
- includes all the short EPC forms, allowing brevity when that is
desirable
This seems to be practical, simple, and almost as elegant as possible.
What do you think?
I changed the text as follows:
Some MNIDs contain sensitive identifiers which, as used in protocols
specified by other SDOs, are only used for signaling during initial
network entry. In such protocols, subsequent exchanges then rely on
a temporary identifier allocated during the initial network entry.
Managing the association between long-lived and temporary identifiers
is outside the scope of this document.
I can't remember exactly why this text was added - it was a long time
ago. But anyway the main point is to simply mention that there may be
associations between some of the MNID types that might be important from
a security standpoint, without meaning to go into examples.
Certainly the new text is clear enough.
Dale