1. The sub-option length could use a fixed unit.
The current definition is:
LuriLength: The length of the LuriValue, not including the
LuriLength field itself, up to a maximum of 255
units. The unit of measurement is defined by the
LuriType field definition. The LuriLength itself is
always a one-byte unsigned integer.
Defining length as being dependent on extension type makes this a lot less extensible. Any LuriType that follows an unsupported LuriType cannot be interpreted because the length of the unsupported LuriType is unknown.
I suggest changing this to use bytes:
LuriLength: LuriLength is a one-byte unsigned integer
containing the length of the LuriValue in bytes,
up to a maximum of 255 bytes.
2. The rules for handling multiple sub-options with the same LuriType need to be defined.
This is less important, because extensions can make their own rules about how multiple sub-options with the same LuriType, but the rules need to be defined for LuriType=1 at least.
I suggest something like:
Unless specified in the definition of a LuriType, multiple
values for the same LuriType are invalid. Multiple values for
an unknown or unsupported LuriType MUST be ignored.
Followed by either:
Multiple values for a LuriType of 1 (location URI) are allowed.
Each LuriValue for LuriType=1 represents a different location URI.
Or:
Multiple values for a LuriType of 1 (location URI) are concatenated.
I prefer the former, but understand that restricting URI length to 255 bytes is potentially troublesome.
On a related point, the following text is inaccurate and should be removed:
Per [RFC2131], subsequent LocationURI Options, which are
non-concatenated, overwrite the previous value.
RFC 3396 is pretty clear on this point:
[...] RFC 2131 [3] specifies that when more than
one option with a given type code appears in the DHCP packet, all
such options should be concatenated together.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
