I hope that we could consider it at the IPP meeting next week
in the vein of "plugging holes"
(and because it was an old action item from 8/20).
Thanks,
Tom
>Return-Path: <ipp-owner@pwg.org>
>X-Sender: hastings@zazen
>Date: Tue, 9 Sep 1997 10:13:00 PDT
>To: ipp@pwg.org
>From: Tom Hastings <hastings@cp10.es.xerox.com>
>Subject: IPP> MOD - RESEND: proposed "document-formats-detected" attribute
>Sender: ipp-owner@pwg.org
>
>I'm resending the proposal that I made on 8/20
>which was my action item from the 8/20 IPP telecon. The action item was
>to provide a Printer description attribute that lists the document-formats
>that the printer can automatically detect/sense. In other words, to provide
>a Printer description attribute that specifies which document-formats
>that the Printer can detect when the document-format is either (1)
>unspecified or (2) specified as 'application/octet-stream' or whatever we
>specify in IPP (or the registry) is the equivalent of the 'langAutomatic'
>Printer MIB enum.
>
>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..
>
>>From the Printer MIB enum description:
>>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
>
>
>