- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 9 Feb 2004 10:39:00 +0100
- To: Black_David@emc.com
- Cc: uri@w3.org
David, Am 08.02.2004 um 02:31 schrieb Black_David@emc.com: > Stefan, > [...] >> One simple way could be the usage of query parameter or always >> treat the first two path segments as engine/context identifier >> with a defined constant for default values. > > I don't like the defined constant idea as it results in spending > characters in the URI to omit or default the engine and/or context, > and omission or defaulting of these is likely to be quite common. > Spending URI characters to say that the SNMP context is the null > string default seems particularly silly. You're right. Having '//' inside the path will make relative URI references difficult as '//' is the start token of the net_path production. > Would it be acceptable to move the engine/context parts into the > path, but make them optional via using something like "E=" and > "C=" strings to introduce them? If <oid> is an OID (numbers > separated by dots), that would allow all of the following: > > snmp://host/oid > snmp://host/C=context/oid > snmp://host/E=engine/C=context/oid > snmp://host/E=engine/oid That's perfectly legal to define in your scheme. Note that also ';' can have a special meaning in a path segment, so you could also define snmp://host/engine=abc;context=123/oid or even snmp://host/oid;engine=abc;context=123 For me, the last one makes more sense. That would define engine and context as a parameter of the oid. These parameters are really part of the path segment and have nothing to do with the query part of a uri. It really depends on the use. If you want to use relative uri references in the same engine and context, the first one is more elegant. Then you can use "./oid2" and don't have to repeat the engine and context params in the uri ref. //Stefan
Received on Monday, 9 February 2004 04:40:04 UTC