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