Subject: PWG> The Printer Working Group as its own standards body

From: JK Martin <[email-masked]>
Date: Wed, 20 Aug 1997 14:53:12 -0400 (EDT)

The situation with the IETF status of the Job Monitoring MIB is indeed
unfortunate.  I would have preferred to have IETF sanctioning of the
Job MIB effort these past couple of years, particularly since we acted
according to the IETF rules as a working group.

Now some folks are starting to wonder about the relationship between
the PWG and the IETF for standards development and publication:

> Given where we are, however, does it seem at all feasible that we could be
> considered "chartered" and, if not, what do we do now? My interpretation
> of the IESG comments is that the authors should submit an informational
> RFC describing the Job MIB and the PWG should maintain the standard. This
> would be the first "PWG standard". Is the PWG ready for this?
> 
> Harry Lewis - IBM Printing Systems

> I also am disappointed that the IETF has announced the strong stand
> against accepting the Job MIB as a Proposed Standard.  The support
> for this standard by printer vendors has indicated a real need for 
> this effort to progress.  I believe that a Proposed Standard would
> encourage the development of more applications that support the MIB 
> than if the MIB was an Informational RFC.  I would like to obtain a 
> straw vote from the group on this topic.
>
>	Ron Bergman
>	Dataproducts Corp.

Perhaps this situation is the kind of "pain" we in the printer industry
need to experience in order to determine whether printer-related
standards should be formally published by the PWG, rather than through
another, existing standards body (such as the IETF, ISO, etc).

During the current (raging) IPP thread regarding MIME-vs-enum values for
Interpreter identification, Bill Wagner made this comment:

>     However, another point implicit in the recommendation is that an 
>     industry might know more about the needs of their product and their 
>     customers than the IETF/IESG. There may be some merit in this. 
>     
>     Bill Wagner, Osicom/DPI

I think Bill is right on track here...and I'll bet he's not alone
in this thought.

Those of you who, like myself, have been with the PWG from its very
inception recall the various discussions in which I offered the notion
that the PWG should more formally organize itself and produce standards
for our industry under our own recognizance.

The primary opposition to this notion has been along the lines of:

  1. Concern for the long-term existence of the PWG itself, particularly
     for such processes as Type 2 Enumerations, document repository, etc.

  2. Concern that only standards from such well-established groups as
     the IETF, ISO, etc., would be considered "respectable"--and therefore
     widely supported--in the industry.

Now, after nearly fours years in existence (the PWG "birthday" could be
argued as September 1993 with the first DMTF-based meeting for the
Printer MIF), it should be obvious to most folks that the PWG is going
to be around for a very, very long time given the continued rapid pace
of printer- and printing-related network technology development.

I doubt we would have a problem in finding suitable long-term document
repository hosts; in fact, Underscore (the current host of all PWG
public lists and document repositories) is more than willing to
continue that role for the forseeable future.  And, should Underscore
no longer be able to provide those services, it is highly likely that
more than one other PWG participating company would be willing to pick
up those services.

Regarding the "respectability" of a standard, the marketplace is the
sole judge for whether a standard is "real" or not.  Some people seem
to forget that neither HP PCL nor Adobe PostScript is a sanctioned
standard...yet those standards pervade our industry to the point of
becoming veritable household terms.  (Congrats to HP and Adobe. ;-)

What is important now, I believe, is the public position stated by
our IETF Area Directors that they have no problem in accepting
"Informational" RFC's from the PWG.  For those who might be concerned
that an Informational RFC is not respectable, consider the situation
with RFC 1179 (LPR/LPD)--it is only an Informational RFC, yet is
considered a full-fledged "standard" by almost everyone.  And, more
importantly, almost every vendor uses RFC 1179 as the basis for their
support for LPR/LPD (with suitable hacks and warts, of course.)

Therefore, I would propose that the PWG start using the IETF-based
Informational RFC mechanism for publishing standards in the future,
at least until we start publishing standards under the PWG banner itself.

The PWG has always used the same basic philosophy for participation as
the IETF--namely, free membership open to anyone.  As long as this
continues (and there's no reason why it shouldn't), Informational RFC's
should be perfectly acceptable to help the printer industry improve the
state of standardization in the industry.

Comments?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 21 Aug 1997 10:02:06 +0200

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