Am 29.11.2009 um 22:25 schrieb Anthony Bryan:
so, you proposed a range of 1 to 255... any objections or other suggestions? :)
Regarding metaurl and url, doesn't this effectively limit the number of (ordered) metaurls/urls to 255? This would seem like an arbitrary - and needless- restriction to me. There should be no reason why the specification should forbid 1000 urls that are all ordered, which could be a valid use case, for whatever reason. I agree that the spec should be definite, but it shouldn't put up restrictions that are not needed I think. If limiting the numbers, I'd suggest a reasonably large range that matches a commonly used datatype, like a short int (16-bit) or an int (32-bit), which would leave ample room (one would think).
However, the spec doesn't give any guidance yet about the use case of the priorities. The use case we have in mind is that we start with 1 (highest priority) (where we started with 99 in the past and counted in the opposite direction), and then increment the value, right? That could be made explicit (although there doesn't need to be a requirement about fixed increments either). Anyway, the relative difference of the priorities is what matters. Maybe an alternative to defining a fixed a range could be to describe a suggested usage; because if people start counting at 1 and use increments of 1, and not 10 or 100 (which they might happen to do), the chances of hitting funny limits would be much higher.
Even _if_ specifying a range, it might be useful to suggest the following: a client that can process datatypes only of a certain size might ignore those entries that come with a higher (larger number) priority than whatever their implementation choses to being unable to process. Does this make sense? Or am I crazy? :-)
Altogether, I think it would be useful if the spec suggests to start counting at 1, increment in steps of 1, _in_order_to_ decrease the chances that any potential client might run into a limit. A client should support at least priorities to 255 (absolute minimum), but better one byte more ;-)
Well, it's just my opinion. Difficult matters. One should have more experience in protocol design ;) Peter
smime.p7s
Description: S/MIME cryptographic signature
