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