Harald suggested that we could use 'application/octet-stream' MIME-type to
indicate automatic document-format sensing or we might want to register
a MIME-type expoicitly for that purpose. So one of the justfications for this
new attribute: that we couldn't have a MIME-type for automatic sensing goes
away. However, I still believe that we still need the attribute so that
the client and end-users can determine which document-formats are automatically
sensed and which ones require that the end-user or client specify
the document-format as an IPP input attribute.
Here is the proposal again. As before I've included several different
attribute names and values for us to pick from, depending on what gets the
idea across the most clearly.
(Also I removed the first justification for the attribute).
I hope we could discuss it at the Wed 8/10 telecon.
Thanks,
Tom
>Return-Path: <ipp-owner@pwg.org>
>X-Sender: hastings@zazen
>Date: Wed, 20 Aug 1997 15:09:18 PDT
>To: ipp@pwg.org
>From: Tom Hastings <hastings@cp10.es.xerox.com>
>Subject: IPP> MOD - document-format-supported using MIME types and
> 'automatic'
>Cc: jmp@pwg.org, pmp@pwg.org
>Sender: ipp-owner@pwg.org
>
>We had an IPP telecon today and discussed the issue of changing IPP from
>using Printer MIB enums for document-format to using MIME-types.
>
>Attending: Steve Zilles, Ira McDonald, Lee Farrell, Roger deBry, Tom Hastings
>
>I took the action item to write up the discussion on this point.
>
snip..
>langAutomatic(37),
> -- Automatic PDL sensing. Automatic
> -- sensing of the interpreter
> -- language family by the printer
> -- examining the document content.
> -- Which actual interpreter language
> -- families are sensed depends on
> -- the printer implementation.
>
>
>The solution that we came up with today [8/20] for IPP is to add a
>Printer description attribute called: "document-formats-detected" (or
>"document-formats-auto-sensed"?). This new IPP attribute solves the problem:
>
>Make it clear to the client which of the document-formats-supported
>can be auto-sensed. Some implementations support more document-formats
>than can be automatically sensed. For example, some implementation support
>PostScript, PJL, and some document format that cannot be reliabilbly sensed.
>
>The "document-formats-detected" Printer attribute would be multi-valued
>that parallels the "document-formats-supporter Printer attribute and
>has a value for each of the values of the "document-formats-supported"
>Printer attribute. Each value would be a keyword that indicates whether the
>corresponding document format is auto-sensed or not. Perhaps, we can even
>have more than two keyword values depending on the degree or reliability
>that the PDL can be sensed. The keyword values might be:
>
> 'auto-detected'
> 'auto-detected-best-effort'
> 'not-auto-detected'
>
>or using the Printer MIB terminology of 'sense', instead of 'detect':
>
> 'auto-sensed'
> 'auto-sensed-best-effort'
> 'not-auto-sensed'
>
>Alternatively, the same values could indicate whether the
>client needs to supply the "document-format" attribute when submitting
>each document or not, so that the following keyword values might be better
>names for the corresponding semantics:
>
> 'document-format-not-required'
> 'document-format-recommended'
> 'document-format-required'
>
For example, the MIME-type for simpleText (whatever that is) would
be indicated with the value: 'document-format-required'. Then it would be
to the clear to the client/end-user that the client must explicitly supply
the IPP attribute:
"document-format"='application/simpleText'
to force simple text, such as a PostScript programmer dumping a PostScript
program as simple text, in order to prevent the Printer from autosensing
the file and interpreting it as PostScript.
snip...
>Comments?
>
>Tom