In the style of the W3C....
+1
**********************************************
Don Wright don at lexmark.com
Chair, IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright at ieee.org / f.wright at computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************
"Zehler, Peter" <PZehler at crt.xerox.com>@pwg.org on 04/28/2003 12:07:15 PM
Sent by: owner-ipp at pwg.org
To: "'carl at manros.com'" <carl at manros.com>, "Zehler, Peter"
<PZehler at crt.xerox.com>, "'McDonald, Ira'"
<imcdonald at sharplabs.com>, ipp at pwg.org
cc:
Subject: RE: IPP> Should we do a PWG IPP/1.2 standard?
Carl-Uno,
What's an IETF? My objective is to get something, other than an rfc on
mail
or evil bits in IP headers, published. And I want to do it in a timely
manner. I do not have the luxury of waiting years for our pleads with the
IETF to be heard. The IETF appears to have little interest in addressing
the boring subject of printing even though that it is a major source of
support calls from real users.
I want to reach consensus and demonstrate interoperable implementations
before I worry about how long, or if, the IETF will take to move this
standard forward.
Pete
-----Original Message-----
From: Carl [mailto:carl at manros.com]
Sent: Monday, April 28, 2003 11:08 AM
To: Zehler, Peter; 'McDonald, Ira'; ipp at pwg.org
Subject: RE: IPP> Should we do a PWG IPP/1.2 standard?
Peter,
When you talk about an IPP/1.2 spec are you expecting that to be published
by the IETF?
If so, should we plan to hold an IPP WG meeting in the next IETF Meeting
(Vienna in July)?
Carl-Uno
Carl-Uno Manros
700 Carnegie Street #3724
Henderson, NV 89052, USA
Tel +1-702-617-9414
Fax +1-702-617-9417
Mob +1-702-525-0727
Email carl at manros.com
Web www.manros.com
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Zehler,
> Peter
> Sent: Monday, April 28, 2003 4:47 AM
> To: 'McDonald, Ira'; 'ipp at pwg.org'
> Subject: RE: IPP> Should we do a PWG IPP/1.2 standard?
>>> All,
>> I think an IPP v1.2 would be a good idea. It would give us an
opportunity
> to collect all the extensions into a single document. (A one
> stop shop for
> IPP as opposed to about 1500 pages spread over some 28 documents) This
> would also give us an opportunity for another Bake-Off. We have
> done a very
> good job on interoperability on the core specs. I am unsure
> about the level
> interoperability of the various extensions. I know some problems already
> exist.
>> Pete
>> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> Sent: Thursday, April 24, 2003 5:51 PM
> To: 'ipp at pwg.org'
> Subject: IPP> Should we do a PWG IPP/1.2 standard?
>>> Hi,
>> Dennis Carney (IBM) recently observed that the IPP Document Object
> spec was starting to sound a lot like "IPP/1.2". Below, Michael
> Sweet (CUPS) again raises the possibility of an "IPP.1.2".
>> Is this a worthwhile idea?
>> _If_ there was at least one other editor who was MS Word literate
> (Dennis Carney, Tom Hastings, ...?), I would volunteer to collaborate
> on writing an "IPP/1.2" spec with new significantly higher REQUIRED
> features that consisted entirely (or almost entirely) of pointers to
> the definitions of operations, objects, and attributes in the over 30
> documents (IETF and IEEE/ISTO) that currently specify parts of IPP.
>> Any takers?
>> Cheers,
> - Ira McDonald
> High North Inc
>>> ----- Excerpt ------
>> Michael Sweet wrote:
> >Hastings, Tom N wrote:
> >> ...
> >> 1. DEPRECATE the way a client can close a Job by supplying an empty
> >
> >Hmm, knowing that people are busy, etc., what are the chances that
> >we do an IPP/1.2 specification based upon the current 1.1 docs +
> >the common extensions (collections, notifications?, job-and-printer
> >ops, plus the document object stuff)?
> >
> >This is another extension which is pointing to an IPP/1.2 version
> >bump - deprecating operations is something that should be reserved
> >for new versions, since otherwise you might not have at least 1
> >version to provide a transition period...
> >
>