Re: prtChannelProtocolVersion

[JK Martin <[e-mail]>]

Harry,

> I've run across an area that is easy to misinterpret. As you might guess, it's
> part of the Channel Group. The object in question is prtChannelProtocolVersion.
> 
> It's not always clear to understand what was intended. For instance, in the
> prtChannelType is chSerialPort (3), some folks naturally want to put things
> like RS-232 or RS-422 etc in the Version but this is actually calling out the
> protocol, not the version. For cases where the prtChannelType is actually a
> protocol (FTP or NPAP) then we would expect a "Version Number" like NPAP 1.1.
> 
> There's probably lots of ways we could address this ambiguity. I'm not making
> any specific suggestions at this point. I'd just like to know if others have
> run into this and what they are doing about it. Are people mixing protocol
> names and version in this object depending on the ChannelType? Does anyone
> think it really matters?
> 

The prtChannelProtocolVersion object was supposed to be (as I recall) a
simple display string...but it's definition is OCTET STRING (max of 63 bytes),
so hopefully that is sufficient for "displayable" kinds of things.

You're absolutely right about the general ambiguity of both the spec and
the intent for this object.  My personal feeling is that this object should
be used by manager software for "identification" purposes; that is, the
value of the object is meant to be displayed to a human (or equivalent),
allowing the human to make whatever semantic judgements are necessary.

Yeah, it would be *very* nice to have standardized strings, but that's
virtually impossible the way things stand now.  What we could do, however,
is provide a "clarifications section" that "suggests" the values for
certain protocol situations, thereby "guiding" an agent implementor to
use somewhat standardized string values.

By the way, how is IBM approaching the problem of setting this value?

	...jay