Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

[Paul Kyzivat <[e-mail]>]

On 9/28/11 8:29 PM, Dean Willis wrote:
[snip]
> However, making sure they don't run out of inventory probably IS our
> problem.
>
> While I agree that 32 bits is PROBABLY enough for the forseeable future,
> if we're going to do something besides ITAD then we might as well go to
> 64. But if we're happy with ITAD structurally, there may not be enough
> justification to do more.

I agree with Dean here:

*If* you think 32 bits is enough, then there has been no *justification* 
for inventing something new rather than using ITADs.

And I'm inclined to think that 32 bits is enough, because the intended 
use will probably mutate into something different before the 32 bits are 
exhausted.

But, if you think 32 is not enough, then 64 is an obvious number to 
choose. An argument was raised against 64 bits because of the encoded 
size (20 bits). But this is only if encoded in decimal.

Why not encode in hex, or radix 64? Here are the number of characters 
required to encode 32 or 64 bits in decimal, hex, and radix64:

            size(bits)
Encoding |  32 | 64
---------+-----+-----
  decimal |  10 | 20
---------+-----+-----
  hex     |   8 | 16
---------+-----+-----
  radix64 |   6 | 11

If 10 decimal bytes were ok, wouldn't 11 radix64 bytes be?

	Thanks,
	Paul