RE: SNMP URI and 2396bis

Stefan,

> > 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.

I agree that these parameters are part of the path segment,
but they're really hierarchical path components (that
can be defaulted via omission) rather than parameters.

> 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.

There appear to be good uses for relative URI references
in the same engine and context, so the first choice makes
more sense.  I assume it's ok to define ';' as a separator
rather than as something that introduces context so that
one gets
	snmp://host/context=123/oid
rather than 
	snmp://host/;context=123/oid
FWIW, the existing draft uses ':' for this separation (as
to a first approximation engine:context::host:port), and
we (draft authors) may just stick with that.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Received on Monday, 9 February 2004 16:29:25 UTC