Hi Ron,
OK - we'll wait for some further feedback from Mike and
Ivan (and Harry?). It seems we're converging (below).
Unfortunately, it's unlikely that there will be a stable
draft WITH introductory text in time for the Portland
meeting in early January.
Most people are now or will soon be on vacation for the
rest of this calendar year. Nancy and I will be moving
south to Ann Arbor for the winter early next week.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
Sent: Tuesday, December 14, 2004 8:11 PM
To: McDonald, Ira; pwg at pwg.org; Mike Fenelon; Ivan Pavicevic; Harry
Lewis
Subject: RE: Posted draft Printer Port Monitor MIB (10 Dec 2004)
Hi Ira,
More replies inline denoted by <ron-2>. I rest my case until
we hear from others.
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Monday, December 13, 2004 5:01 PM
To: Bergman, Ron; McDonald, Ira; pwg at pwg.org; Mike Fenelon; Ivan
Pavicevic; Harry Lewis
Subject: RE: Posted draft Printer Port Monitor MIB (10 Dec 2004)
Hi Ron,
Replies to your replies inline (smile).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
Sent: Monday, December 13, 2004 6:27 PM
To: McDonald, Ira; pwg at pwg.org; Mike Fenelon; Ivan Pavicevic; Harry
Lewis
Subject: RE: Posted draft Printer Port Monitor MIB (10 Dec 2004)
Hi Ira,
My responses to your replies are also inline.
Ron
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Monday, December 13, 2004 2:30 PM
To: Bergman, Ron; McDonald, Ira; pwg at pwg.org; Mike Fenelon; Ivan
Pavicevic; Harry Lewis
Subject: RE: Posted draft Printer Port Monitor MIB (10 Dec 2004)
Hi Ron,
Replies inline below.
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Bergman, Ron [mailto:Ron.Bergman at rpsa.ricoh.com]
Sent: Monday, December 13, 2004 4:28 PM
To: McDonald, Ira; pwg at pwg.org; Mike Fenelon; Ivan Pavicevic; Harry
Lewis
Subject: RE: Posted draft Printer Port Monitor MIB (10 Dec 2004)
Ira,
Its much better! Some minor comments:
1. ppmGeneralNaturalLanguage SIZE(0..63):
The actual max is currently 3. If a null string, this value
must be at least 4. I suggest 6 or 8.
<ira> This is NOT equivalent to 'prtLocalizationLanguage'
Per IPP and Semantic Model, all new PWG std interfaces MUST
support a full RFC 3066 'language tag' as follows:
"The syntax of this tag in ABNF [RFC 2234] is:
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)"
For example, "en-US"
</ira>
<ron> Ok, I now count 18 max and 8 expected (with a terminating
null). Why do we need to specify 63?
</ron>
<ira>
You mis-read that ABNF - language tags in IETF and W3C standards
are of _unlimited_ length - the new RFC 3066 revision (in last
call) adds MANY script/dialect/variant subtags. Now many European
languages/dialects need quite long tags. IPP and PWG Semantic
Model in fact require a 127 char max (I shortened it here).
The latest ABNF (already in PWG Semantic Model patterns) is:
= lang *("-" extlang) ["-" script] ["-" region] *("-" variant)
=/ *("-" extension) *("-" private_use)
=/ private_use ; private use tag
=/ grandfathered ; grandfathered registrations
Current examples in that draft include:
'zh-Hans-CN' (Simplified Chinese for the PRC)
'sr-Latn-891' (Serbian written in Latin script (instead of
Cyrillic) for Serbia and Montenegro)
</ira>
<ron-2> Accepted! </ron-2>
2. ppmGeneralNumberOfPorts: Can't the DEFVAL be omitted without
an explanation?
<ira>
I really dislike the theory that explanations should be deleted
</ira>
<ron> It just seems to be out of place here. Why is there not a
similar explanation in ppmPortIndex?
</ron>
<ira>
Because index objects have never permitted a DEFVAL.
Counter32 and Gauge32 are unique, in that they are constructed
types that don't allow a DEFVAL (for arcane reasons...).
</ira>
<ron-2> My objection here is just how it is presented. Rather
than a commented out DEFVAL, a note in the description
clause would be more appropriate, such as: "A valid
value must be present, since a DEFVAL is not permitted
in Counter32 objects."
</ron-2>
3. ppmPortProtocolType: If the value is other(1), then it is
specified as a protocol other than a defined type. The note
should be removed.
<ira>
There is no defined value for 'unknown' in 'PrtChannelTypeTC'.
There is an actual requirement in well-written MIBs to include
DEFVALs for all possible objects (part of SMIv2 standards).
</ira>
<ron> Under what conditions will the printer not know the
protocol type? If I don't know the type why would it be
reported here? (This is a NIT, but weirdness like this
bothers me.)
</ron>
<ira>
The reason DEFVALs are required in well-formed SMIv2 MIBs is
to guarantee that there is a well-known initial value that
every SNMP Agent will set in the object - we're stuck with
'other' (implicitly, even if we erroneously leave out the
DEFVAL clause here)
</ira>
<ron-2> My problem here is defining "other" to be "unknown".
If we must have a DEFVAL, other(1) is as good as any.
</ron-2>
4. ppmPortProtocoPortNumber: chIpp(42) should be removed since
the target protocols are only LPR and RAW TCP.
<ira> No - this is a PWG standard MIB that can use ANY of the
defined channel types, not just LPR or RAW. The IPP example
is appropriate (Harry Lewis suggested it!).
</ira>
<ron> There should be a detailed explanation in the discussion
on this subject. However, since the target application
for this MIB only looks for LPR and RAW TCP, this may
cause some confusion here. I know we would like this to
be general, but other changes would still have to be made
for a truly general MIB. (e.g. ppmPortLprQueueName)
</ron>
<ira>
The MICROSOFT target is LPR/RAW. But a PWG Standard MIB is
NEVER only for one vendor's purpose. If the MIB is truly
only for Microsoft's use (and NOT to be used by management
tools and other vendors' driver installations), then Microsoft
should hack their own private MIB - that is not the business
of the PWG.
</ira>
<ron-2> Actually it is for all printer vendors and Microsoft.
I am not proposing not making it work for other
applications. Since it will definitely be used by
Microsoft and maybe by some other applications, I
would like to not imply that Microsoft will be using
the MIB to recognize IPP. The TBD introductory section
must contain the facts you discuss above and can also
indicate that IPP and other protocols are certainly
acceptable in this object when used by other than the
Microsoft port monitor. It should also state that
protocols not recognized or supported by the MS Port
Monitor or any other application using this MIB must
be ignored.
Again, I do not believe this is a major issue and I
am only trying to prevent any misunderstanding later.
If everyone agrees with you that removing this example
maske this a private MS MIB, then I withdraw the comment.
</ron-2>
5. ppmPortQueueName: The LPR queue name cannot be unknown. The
MS document originally defined the default as "LPR".
<ira>
The point is that it's unspecified, if empty. The default queue
name in RFC 1179 is certainly not "LPR".
</ira>
<ron> If the queue name is not known, of what benefit is there
to return any information? An LPR channel must have a
queue name.
</ron>
<ira>
There is not any possible single non-empty default value that
will apply and operate across all vendors' implementations
of LPR - that's the problem of the customer and the specific
vendor.
</ira>
<ron-2) Again a minor point. I suspected that Microsoft
encountered a large number of implementations that
use "LPR". I did not mean to imply this will work
with every printer in the universe.
</ron-2>
6. ppmPortLprByteCountEnabled: Add: "Ignored if
'ppmPortProtocolType' is not 'chLPDServer(8)."
<ira>
OK!
</ira>
Some of the notes should be moved into the future introductory
text and others should just be merged into the DESCRIPTION
clause. The 'notes:' should only be used only for information
that is not obvious to a well-informed reader and should be
used sparingly.
<ira>
No - delete the word 'Note:', but these explanations belong in
the MIB - customers and users who have compiled this MIB ONLY
see the DESCRIPTION and REFERENCE clauses in their management
tools - the outside text is lost forever - and not available,
since PWG standards are never published in plaintext.
</ira>
<ron> This subject should be deferred until later. In general
I agree, but there may be one or two cases where the
text should be revised with more explanation in the
introductory text and less in the MIB.
</ron>
<ira>
Because the PWG has firmly (in their Process v1 and Process v2)
decided that they will NOT publish any standard in plaintext,
for practical purposes (real customers and network managers)
there is NO introductory text. None of the standard network
management vendors distribute richtext source with MIBs.
</ira>
<ron-2> So SNMP implementers cannot read anything but plaintext?
There is much implementation information that is
normally outside of the actual MIB that is not needed
in using the MIB. We certainly do not want everything
presented to the management application.
</ron-2>
Ron
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Friday, December 10, 2004 12:29 PM
To: 'pwg at pwg.org'; 'Mike Fenelon'; Ivan Pavicevic; Bergman, Ron;
McDonald, Ira; Harry Lewis
Subject: Posted draft Printer Port Monitor MIB (10 Dec 2004)
Hi folks, Friday (10 December 2004)
Based on comments from Mike, Ivan, Ron, and Harry, I have just posted a
second draft of the PWG Printer Port Monitor MIB at:
ftp://ftp.pwg.org/pub/pwg/BOFs/port/tb-portmib10-20041210.mib
(Enclosing IEEE/ISTO PWG boilerplate will written after email comments
and our review on January 12 at the PWG face-to-face in Camas, WA.)
Comments?
Cheers,
- Ira
----------------------------------------
[change log included in MIB]
REVISION "0412100000Z" -- 10 December 2004 (v0.20)
DESCRIPTION "Second draft of PWG Printer Port Monitor MIB.
- added Ivan to editors (oversight in v0.10),
per request of Mike and Ivan;
- added IMPORT of 'PrtChannelTypeTC' from
IANA-PRINTER-MIB (first published in RFC 3805)
and changed SYNTAX of 'ppmPortProtocolType',
per request of Ron Bergman;
- renamed 'PpmTextStringTC' textual convention to
'PpmLocalizedStringTC' (for clarity);
- added 'ppmGeneralNumberOfPorts' to General group,
to align with Mike and Ivan's original draft;
- revised 'ppmPortProtocolType' to specify the IANA
Printer MIB as the authoritative source of values,
per request of Ron Bergman;
- revised 'ppmPortProtocolPortNumber' to specify
that, if zero, then the default port for the
current value of 'ppmPortProtocolType' is used,
per request of Harry Lewis;
- revised 'ppmPortIEEE1284DeviceId' to clarify more
format details and restricted characters,
per request of Mike and Ivan;
- moved 'ppmGeneralCommunityName' and renamed to
'ppmPortSnmpCommunityName' (for clarity),
to align with Mike and Ivan's original draft;
- renamed 'ppmPortStatusQueryEnabled' to
'ppmPortSnmpStatusQueryEnabled' (for clarity),
to align with Mike and Ivan's original draft;
- deleted 'ppmPortDescription' (redundant),
per request of Mike and Ivan;
- deleted 'ppmPortPrtChannelIndex' and
'ppmPortInterfaceIndex' (not necessary),
per request of Mike and Ivan."
REVISION "0411180000Z" -- 18 November 2004 (v0.10)
DESCRIPTION "First draft of PWG Printer Port Monitor MIB.
- content from Mike and Ivan's original draft and
a few proposed extensions."
----------------------------------------