W3C home > Mailing lists > Public > uri@w3.org > February 2004

Re: SNMP URI and 2396bis

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 9 Feb 2004 10:39:00 +0100
Message-Id: <CA0850E8-5AE3-11D8-9299-00039384827E@greenbytes.de>
Cc: uri@w3.org
To: Black_David@emc.com

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC