Subject: IPP> MOD - RESEND: proposed "document-formats-detected" attribute

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Sep 1997 19:39:21 PDT

We missed considering this old proposal at the telecon today.

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: <[email-masked]>
>X-Sender: hastings@zazen
>Date: Tue, 9 Sep 1997 10:13:00 PDT
>To: [email-masked]
>From: Tom Hastings <[email-masked]>
>Subject: IPP> MOD - RESEND: proposed "document-formats-detected" attribute 
>Sender: [email-masked]
>
>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: <[email-masked]>
>>X-Sender: hastings@zazen
>>Date: Wed, 20 Aug 1997 15:09:18 PDT
>>To: [email-masked]
>>From: Tom Hastings <[email-masked]>
>>Subject: IPP> MOD - document-format-supported using MIME types and
>>  'automatic'
>>Cc: [email-masked], [email-masked]
>>Sender: [email-masked]
>>
>>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
>
>
>