Hi Bob,
See some replies inline below. Thanks very much for thinking
hard about these issues.
High level comment - I'm ready to throw in the towel and declare
that for machine-readable and machine-actionable needs the addition
of parameters to MIME types is a non-solution.
So I think we're back to a structure/object for PSI, SM, IPP, etc.
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com]
Sent: Monday, November 04, 2002 1:19 AM
To: McDonald, Ira; 'ps@pwg.org'; 'hastings@cp10.es.xerox.com'
Cc: SIMPSON,SHELL (HP-Boise,ex1)
Subject: RE: PS> Further Revised PWG std MIME parameters ABNF (25 Oct
2002 )
Hi Ira,
See a couple of specific comments below - with large chunks trimmed
since I agreed and wanted to make it more readable.
bt
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
>
> - The proposal explicitly states in several places "Human-readable
> information,
> suitable for client UI and debug. Not suitable for use by automata".
> Given
> that we do need to use content type information for automata, is it
> assumed
> that something else (e.g., a "structure" definition) must
> be defined as
> well?
>
> <ira>
> The proposal _notes_ the current definition of the proposed
> information
> in Printer MIB v1 (RFC 1759, March 1995) as "human-readable".
>
> But PSI shouldn't solve this problem without a clear IPP binding of
> whatever the "solution" is.
>
> (I can now almost hear myself suggesting an IPP binding based on
> "document-format-col (1setOf collection)" - yuck! - an awful
> solution for IPP).
>
> A good long-term solution for IPP would be to use the
> proposed generic
> Resource object and (just as we've proposed for "media" as a _much_
> better solution than the "media-col" attributes) define a
> Document Format
> type of Resource.
> </ira>
<bt>
Agreed - but our (HP) interest is primarily in PSI & SM, where we can use
the structural flexibility of XML. I don't have a problem with defining
an IPP structure for this, but we need to define something quickly for
PSI and SM, so I'd advocate maybe doing these first on this one.
</bt>
<ira>
I agree that we need some solution very quickly for PSI and SMI.
But I started on this problem because it was identified for FSG PAPI
and FSG Job Ticket (both of which HP is certainly interested in, too).
I'm OK with pursuing an XML structure solution for PSI and SM first.
But I'd like to aggressively work on how to pass this in either
IPP Printer object attributes or IPP (new Resource) object attributes,
so that Free Software Group Open Printing isn't at a disadvantage.
</ira>
>
> model -- Target device for which the data was created.
> PDLs (such as
> Postscript or PCL) can include printer model specific
> information.
> (Each
> printer model has its own specific language specification.)
>
> <ira>
> Can you suggest a deterministic, portable way to enumerate
> printer models
> that interoperates across software and hardware vendors? Again, a PWG
> registry is an unacceptable (and unworkable) solution, I believe.
> </ira>
<bt>
Could we just spec that standard IEEE1284 DeviceIDs be used? I believe
these are already deterministic, and also can declare "compatible"
models to provide hints on what other models may understand a datastream.
</bt>
<ira>
Yes, IEEE1284 DeviceID is probably a good solution for device model.
And it's a stable registry that we (PWG) don't have to maintain.
</ira>
This archive was generated by hypermail 2b29 : Mon Nov 04 2002 - 13:59:25 EST