Harald,
For your review of the Job Monitoring MIB, our latest Job Monitoring MIB
Internet-Draft has included indications of coded character set data for both
the data originating from a job submitter and from a server.
The latest draft also includes identifying documents-formats using
the Printer MIB enums and the MIME-types.
We are trying hard to meet the IETF and IESG requirements for
a standards track document.
The latest draft is: <draft-ietf-printmib-job-monitor-05.txt>
Tom
At 01:02 08/21/97 PDT, Harald.T.Alvestrand at uninett.no wrote:
>Jay,
>good points.
>>The relationship between the IETF and non-IETF groups has always been
>worrisome; in some cases, we have seen things that looked as if someone
>outside the IETF wanted to use the IETF as a tool to get the "community"
>to endorse a position that couldn't be sold on its own merits, AND place
>the IETF in a position where it couldn't insist on obvious weaknesses
>in the protcol being repaired.
>The discussions around Sun RPC and NFS focused around this issue; it is
>also one of the things currently making the S/MIME debate so strident.
>>In other cases, the IETF community knows that it does not add significant
>value to the process of getting a standard done; the IETF is aggressively
>uninterested in specifying the number of pins on serial plugs or the
>precedence of operators in the C language, to name two instances, although
>both efforts are obviously important to our user community.
>Recent instances are our non-involvement in the SET payment protocol and
>our closing down of work on HTML.
>(This is of course a fluid point, since the set of people in the IETF
>community,
>and therefore its expertise, changes over time - after all, the IPP *is*
>part of the IETF community.)
>>The standards process is the process the IETF has that places a stamp
>of approval on specifications. Obviously, we have to be careful what we
>use it for.
>>The IETF should, IMHO, NOT standardize things in the following cases:
>>- The proposal is not going to be used in or around the Internet
>- The proposal cannot be evaluated by IETF experts for lack of competence
>- The proposal cannot be modified if the IETF community thinks that it
> needs modification
>- The proposal does not fit with IETF policy
>>The last one is a flexible point again; some examples include requiring use of
>patented or encumbered technology when freely available alternatives
>exist, mandating use of cleartext passwords, standardizing very complex
>protocols when simpler solutions solve most of the problem.
>It's a judgment call.
>>Since the bandwidth of those who have to do the judging (the IESG) is limited,
>and since we know we're not infallible, we don't want this process to limit
>publication of documents, even though we don't necessarily agree with them.
>>Therefore, RFC publication, which has a reputation as a stable reference,
>is available for non-IETF documents in "informational" form. We sometimes
>ask for review of informationals, but only attempt to block publication of
>them when we regard the content as misleading (such as labelling itself
>"Internet Standard") or that publication would lead to confusion in the
>community (such as having a fight about 2 approaches in a WG, and the
>"loser" being published before the "standard").
>>I've scheduled the Job MIB on my list of things to look at; let's hope
>things get sorted out correctly!
>Regards,
>> Harald T. Alvestrand
>>>>>>