Re: Version -02 of draft-polk-dhc-uri available for review
At the meeting I said that I was not so happy that there was one
single option for all types of URIs. Let me try to explain why.
The way I read the document, the intention is that this option can
or should be used for any types of URIs? To me that seems very
different from what we usually do. We usually have options for
specific purposes, where a given option value might be a number, a
domain name, and URI or whatever. In some cases an option may be
allowed to have different types of values. Having an option for
all kinds of URIs, sounds a bit like having an option for all
options containing a domain name...
On the other hand, I think I understand where you're coming from.
Having an option for every single type of URI in your list is
probably not a good idea.
If there is a common theme/purpose to all your URIs, we could just
phrase things a bit differently perhaps, not suggesting that it
necessarily is to be used for other URIs.
I'm not sure there is a common theme though. But there seems to be
a set of themes/purposes, where each one possibly could be a
separate option? Without trying to understand how all the
different URIs are actually used, would it for instance be
possible to group geo/civic mapping services into one option, or
SIP/SIPS URIs together? Not sure whether that is right approach,
but you hopefully understand my thinking.
One other disadvantage with current approach I think, is that you
need your own scheme for requesting options, rather than using the
parameter request list option. If URIs are broken down into a few
options for different purposes, maybe one could simply request all
URIs for that purpose? Or do you think it's necessary that client
can ask narrow it down to one particular type of URI in the