Hi Ira,
You can certainly reject my observation, but please do not reject it for
something I did not write. Nowhere do I mention bindings or protocol. I
refer to names and perceived alignment. My contention was that presenting
this as an extension of IPP rather than a new capability that uses existing
protocols and methods does not give it the best advantage. This opinion was
also voiced by someone else at the meeting, although it did not make it to
the minutes. I did not say nor do I necessarily believe that the project
should not be done within the IPP WG.
I am pleased to hear that you are getting good response to IPP/2.0. I am
not, aside from some (maybe unjustified) relief from some that they need not
do anything further.
Bill Wagner
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Tuesday, March 02, 2010 12:56 PM
To: William Wagner; Ira McDonald
Cc: ipp at pwg.org
Subject: Re: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28
February 2010)
Hi Bill,
The discussion during the PWG face-to-face clearly stated that
the protocol for the first iteration of IPP Everywhere will be IPP
application protocol (RFC 2911) over the HTTP/1.1 binding
(RFC 2910).
Non-IPP bindings are way out of scope at present.
IPP Everywhere leverages the considerable momentum
behind IPP/2.0.
I get frequent private notes from implementors at various
of printer vendors working on IPP/2.0 conformance.
I'm opposed to renaming/widening the scope of this project.
If the PWG Steering Committee decides that this project
should move elsewhere from the IPP WG, then we'll have
to consider that in the "Elsewhere" working group.
In my professional experience, most cellphone and PDA
vendors are well aware of IPP, but mostly don't even know
that the PWG exists.
So I don't like choosing a fuzzy name like "Print Everywhere"
(already trademarked, by the way, as is almost every other
conceivable "Print Xxx" name).
Cheers,
- Ira
PS - The text descriptions of almost all of the properties in
Printer MIB v1 was cut-and-paste verbatim from the ISO
10175 MS Word source and then modified - that's why
they're so well aligned.
My HP WJA colleagues last year amusingly discovered
legacy text in the prtInputType object that says "the Input
Class provides..." (and wondered where "Input Class"
was defined - it isn't).
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Tue, Mar 2, 2010 at 12:09 PM, William Wagner <wamwagner at comcast.net>
wrote:
> Quite an exchange! I admit that I rather got lost after the third volley,
> but I see that all is resolved, at least between Ira and Mike.
>> But I would like to bring up an observation made at the face to face,
which
> I thought was quite valid, although it might not seem so to CUPs-oriented
> people. Calling this proposed capability IPP is not an advantage either to
> gain users or implementers. Most users don't know what IPP is, don't use
it
> and don't care. It is my impression that many printer manufacturers have
not
> kept up with it, don’t regard it highly, and want to move on.
>> This is not to say that the proposed capability should not build on IPP,
> just as it may reasonably utilize other existing methods of device
location,
> PDLs, etc. Using what has already been worked out is positive and makes
> adoption more likely. And IPP is, of course, the basis for our MFD
semantic
> model. But tying it in too closely so as to make it just another of the
> flock of IPP spec's may not give it the attention that it deserves.
>> The name suggestion at the Face-to-face was (I think) Print-Everywhere
> (which would need a conflict check) although I think Print-Anywhere is
more
> appropriate (if already a conflict). But the exact name is of less
> importance than presenting this as a new capability building on existing
> protocols and techniques, of which IPP (or perhaps the PWG print service
> semantic model) is one. That is, I believe, what it really is.
>> This capability seems like a good thing to me, but I can hear
> "IPP-Everywhere" falling with a dull thud on the planning room floors.
>> Bill Wagner
>> PS: By the way, without questioning the influence of DPA or Tom Hastings'
> contribution to the Printer MIB, it certainly is not my recollection that
> the Printer MIB was "written by... cut-and-paste from ISO DPA".
>> -----Original Message-----
> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Ira
> McDonald
> Sent: Tuesday, March 02, 2010 9:25 AM
> To: Michael Sweet; Ira McDonald
> Cc: ipp at pwg.org> Subject: [IPP] Re: Initial draft of IPP Everywhere Project Charter (28
> February 2010)
>> Hi Mike,
>> OK - I agree with you.
>> We can do a single IPP Everywhere spec. Especially,
> if we keep the new attribute content minimal.
>> The apparently odd boundaries of Semantic Model work
> can't really be changed now - but it's no impediment to the
> IPP Everywhere work.
>> If we do wind up needing technical changes in CUPS
> Raster or other document format, the SC is probably
> going to make us charter a separate spec, but that's a
> future issue.
>> So, we'll drop the JXS2 work item and just have IPP
> Everywhere Requirements and IPP Everywhere spec.
>> I'll review the rest of your comments and try to put out
> another draft later this week.
>> Cheers,
> - Ira
>> PS - The Printer MIB was in point of fact written by
> Tom Hastings by cut-and-paste from ISO DPA.
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto:blueroofmusic at gmail.com> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>>>> On Mon, Mar 1, 2010 at 11:31 PM, Michael Sweet <msweet at apple.com> wrote:
>> On Mar 1, 2010, at 5:05 PM, Ira McDonald wrote:
>>> Hi,
>>>>>> So you want a single boolean attribute "ipp-everywhere-supported"?
>>>> Since we haven't even started down the road of defining the specifics of
> IPP Everywhere, I can't say whether I will want it.
>>>>> We CANNOT do IPP/2.3 and say "oh that's just IPP Everywhere which
>>> is really a bit more than IPP/2.0". Both RFC 2911 and PWG Process
>>> don't let us play fast-and-loose with minor version numbers - they're
>>> additive in a strict sense.
>>>> I don't recall saying I want to do IPP/2.3. I *did* say that I didn't
> think we needed a profile for each version of IPP/2.0, IPP/2.1, and
IPP/2.2,
> but instead we'd have one profile for IPP/2.0 that would essentially
create
> an IPP/2.05 - IPP/2.0 + what is needed to support basic printing from any
> client. IPP/2.1 and IPP/2.2 printers obviously could support IPP
Everywhere
> as well, but that wouldn't require new versions or "profiles".
>>>>> Yes - after much discussion 10 years ago, the charter of the PWG
>>> Semantic Model WG - no definitions ever - *is* cast in stone.
>>>> I'm not going to argue with you, Ira. But I am concerned that we will end
> up writing another set of specs that doesn't actually accomplish what we
> want.
>>>>> The PWG Multifunction Device WG has to write a spec for every new
>>> attribute they add to the SM. So does IPP WG. That's the point of
>>> the rigid scope of the PWG Semantic Model WG charter.
>>>> In software development, this would be like writing an interface
> definition after you spend years developing the software. Most
> organizations employ some kind of design process (often in parallel with
> prototyping and/or coding) so that the interfaces are well-defined before
> the software is finished, otherwise all you get is chaos.
>>>> So to say that we're going to define all of these attributes and
> operations for a specific protocol first and *then* generalize it in the
> semantic model seems backwards and destined for failure or at least years
of
> delay to get what we have in IPP over to Web Services and other
mappings...
>>>> Consider the Printer MIB - imagine if the model was done first (or in
> parallel) with the MIB. What sorts of changes could you expect? Would the
> resulting MIB be easier to use? Would the mappings to other protocols be
> better/easier to use?
>>>>> The mapping of Printer MIB v2 into the XML schema was done 5 years
>>> ago as part of WIMS/1.0 and has always been included in the PWG SM
>>> XML schema - it's now in System.SystemCapabilities.Subunits.
>>>>>> But an IPP mapping (in the current binary transport encoding) needs
>>> a spec.
>>>>>> To become practical, do you favor a collection attribute or other
lighter
>>> weight (than a first-class IPP Device object) mapping of Printer MIB?
>>> A simple flat mapping to zillions of new IPP Printer attributes is not
>>> likely to be well-received by the other PWG members, I think.
>>>> I think we need to cherry pick the most useful properties. For CUPS we
> found that the printer alert and marker properties are the most important
> additions, although I did end up consolidating the prtMarkerSupplies and
> prtMarkerColorant properties into the marker-* attributes since the
mapping
> from supply to colorant is unnecessarily complicated.
>>>> We already have a spec for the alerts (PSX), and the IPP Everywhere Wiki
> has a page describing the marker-* attributes:
>>>>http://pwg-wiki.wikispaces.com/CUPS+Marker+Attributes>>>> That would yield at most 10 new printer description attributes between
the
> two specs and would provide all of the information needed for a client to
> monitor the current status of a typical printer.
>>>> As for collections, I'm not a big fan since every spec that employs them
> has implemented several layers of nested collections which are less
compact
> and harder to support in software and hardware. For example, media-col
has
> a media-size member attribute collection with two member attributes -
> media-x-dimension and media-y-dimension. After implementing media-col
> support, I am convinced that it would have been better for us to promote
> media-x/y-dimension to be member attributes of media-col directly. 1setOf
> collections are similarly problematic due to the added overhead of the
> member attributes for every instance, although in some cases the overhead
> may be worth it.
>>>>> And the PWG SC has not favored mixing new attributes with profiles.
>>> If we do that, then I *think* we'll never extend IPP Everywhere - and I
>>> don't think we can put PDF or any other rich WYSIWYG document
>>> format in as a REQUIRED in the first IPP Everywhere - otherwise,
>>> what's the point?
>>>> I don't think we will be able to make a "rich" format required in this
> decade if we want support for low-end printers (and I know *I* do).
> However, we *can* expect that typical workgroup and enterprise printers
> will probably support that rich format in order to get the best engine
> performance (many already support PDF...)
>>>>> I imagine IPP Everywhere/1.0 is raster/graphic only and IPP Eve/2.0
>>> adds a WYSIWYG document format or two.
>>>> What's wrong with having a REQUIRED raster format and additional
> RECOMMENDED formats (PDF, etc.)? I just don't see the need for multiple
IPP
> Everywhere versions at this time.
>>>> ________________________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.