SM> PWG Parameters for MIME types ("document-format" values)

SM> PWG Parameters for MIME types ("document-format" values)

SM> PWG Parameters for MIME types ("document-format" values)

McDonald, Ira imcdonald at sharplabs.com
Fri Oct 11 14:09:18 EDT 2002


Hi folks,                                       Friday (11 October 2002)

Per my action item from Tuesday's PSI Telecon:

Below are four proposed PWG standard optional parameters for MIME types,
all extracted directly from the attributes (so-called SNMP 'objects')
defined in the InterpreterTable of the Printer MIB (see comments below).

Any of these PWG parameters MAY be appended (unordered) to any MIME type
value of the IPP/PWG SM "document-format" attribute, for example:

    application/vnd.hp-pcl;pwg-pdl-resolution="400,400,dpi"

These PWG parameters are specified in Augmented Backus-Naur Form (ABNF,
RFC 2234).  Every element used in one of these PWG parameter ABNF
productions is defined in an excerpt from ABNF (RFC 2234), MIME Part One
(RFC 2045), or Internet Message Format (RFC 2822) at the end of this
note.

According to RFC 2045:

(1) Parameters MUST be ignored when unrecognized;
(2) Parameters MUST be ignored when comparing values of MIME types;
(3) MIME type names MUST be treated as case-insensitive;
(4) MIME parameter names MUST be treated as case-insensitive;
(5) MIME parameter values MUST be treated as case-sensitive.

Each parameter name begins with a "pwg-" (namespace) prefix, to ensure
that it is safely ignored by existing MIME-enabled software and systems.


;   prtInterpreterLangLevel             OCTET STRING
;   - not supported in IPP/PWG SM
pdl-level =     "pwg-pdl-level"         ; PDL language level
                "=" quoted-string       ; e.g., "5e" for HP PCL
                                        ; or "2" for Adobe PostScript

;   prtInterpreterLangVersion           OCTET STRING
;   - not supported in IPP/PWG SM
pdl-version =   "pwg-pdl-version"       ; PDL version or date code
                "=" quoted-string       ; e.g., "4027" for PostScript

;   prtInterpreterDescription           PrtLocalizedDescriptionStringTC
;   - not supported in IPP/PWG SM
pdl-desc =      "pwg-pdl-desc"          ; PDL description
                "=" quoted-string       ; e.g., "Adobe PostScript..."

;   prtInterpreterFeedAddressability    Integer32,
;   prtInterpreterXFeedAddressability   Integer32,
;   - see "printer-resolution" in IPP/PWG SM
pdl-res =       "pwg-pdl-resolution"    ; PDL resolution
                "=" quoted-string       ; cross-feed "," feed "," units
                                        ; cross-feed = 1*DIGIT
                                        ; feed       = 1*DIGIT
                                        ; units      = "dpi" / "dpcm"
                                        ; dots/inch or dots/centimeter
                                        ; e.g., "300,600,dpi" means
                                        ; 300 cross-feed X 600 feed DPI


The following Interpreter attributes from the Printer MIB are omitted
(for the reasons noted below):

;   prtInterpreterLangFamily            PrtInterpreterLangFamilyTC,
;   - see "document-format" in IPP/PWG SM

;   prtInterpreterVersion               OCTET STRING,
;   - redundant with prtInterpreterLangVersion

;   prtInterpreterDefaultOrientation    PrtPrintOrientationTC,
;   - see "orientation-requested-default" in IPP/PWG SM

;   prtInterpreterDefaultCharSetIn      IANACharset,
;   - see "charset-configured" in IPP/PWG SM

;   prtInterpreterDefaultCharSetOut     IANACharset,
;   - not supported in IPP/PWG SM - only useful for softcopy output

;   prtInterpreterTwoWay                PrtInterpreterTwoWayTC
;   - not supported in IPP/PWG SM - bidirectional print channel

Cheers,
- Ira McDonald, co-editor of Printer MIB v2
  High North Inc


------------------------------------------------------------------------
[from "MIME Part Two: Media Types", RFC 2046]

>  Parameters are modifiers of the media subtype, and as such do not
>  fundamentally affect the nature of the content.  The set of
   meaningful parameters depends on the media type and subtype.  Most
   parameters are associated with a single specific subtype.  However, a
   given top-level media type may define parameters which are applicable
   to any subtype of that type.  Parameters may be required by their
>  defining media type or subtype or they may be optional.  MIME
>  implementations must also ignore any parameters whose names they do
>  not recognize.


------------------------------------------------------------------------
[from "Augmented BNF for Syntax Specifications (ANBF)", RFC 2234]

DIGIT       =  %x30-39

DQUOTE      =  %x22


------------------------------------------------------------------------
[from "MIME Part One:  Format of Internet Message Bodies", RFC 2045]

parameter = attribute "=" value
  
attribute = token
             ; Matching of attributes
             ; is ALWAYS case-insensitive.

value = token / quoted-string

token = 1*<any (US-ASCII) CHAR except SPACE, CTLs,
            or tspecials>

tspecials =  "(" / ")" / "<" / ">" / "@" /
              "," / ";" / ":" / "\" / <">
              "/" / "[" / "]" / "?" / "="
              ; Must be in quoted-string,
              ; to use within parameter values


------------------------------------------------------------------------
[from "Internet Message Format", RFC 2822]

quoted-string   =       [CFWS]
                        DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                        [CFWS]

   A quoted-string is treated as a unit.  That is, quoted-string is
   identical to atom, semantically.  Since a quoted-string is allowed to
   contain FWS, folding is permitted.  Also note that since quoted-pair
   is allowed in a quoted-string, the quote and backslash characters may
   appear in a quoted-string so long as they appear as a quoted-pair.

   Semantically, neither the optional CFWS outside of the quote
   characters nor the quote characters themselves are part of the
   quoted-string; the quoted-string is what is contained between the two
   quote characters.  As stated earlier, the "\" in any quoted-pair and
   the CRLF in any FWS/CFWS that appears within the quoted-string are
   semantically "invisible" and therefore not part of the quoted-string
   either.

<...>

CFWS            =       *([FWS] comment) (([FWS] comment) / FWS)

FWS             =       ([*WSP CRLF] 1*WSP) /   ; Folding white space
                        obs-FWS

ctext           =       NO-WS-CTL /     ; Non white space controls

                        %d33-39 /       ; The rest of the US-ASCII
                        %d42-91 /       ;  characters not including "(",
                        %d93-126        ;  ")", or "\"

ccontent        =       ctext / quoted-pair / comment

comment         =       "(" *([FWS] ccontent) [FWS] ")"

   Throughout this standard, where FWS (the folding white space token)
   appears, it indicates a place where header folding, as discussed in
   section 2.2.3, may take place.  Wherever header folding appears in a
   message (that is, a header field body containing a CRLF followed by
   any WSP), header unfolding (removal of the CRLF) is performed before
   any further lexical analysis is performed on that header field
   according to this standard.  That is to say, any CRLF that appears in
   FWS is semantically "invisible."

   A comment is normally used in a structured field body to provide some
   human readable informational text.  Since a comment is allowed to
   contain FWS, folding is permitted within the comment.  Also note that
   since quoted-pair is allowed in a comment, the parentheses and
   backslash characters may appear in a comment so long as they appear
   as a quoted-pair.  Semantically, the enclosing parentheses are not
   part of the comment; the comment is what is contained between the two
   parentheses.  As stated earlier, the "\" in any quoted-pair and the
   CRLF in any FWS that appears within the comment are semantically
   "invisible" and therefore not part of the comment either.

   Runs of FWS, comment or CFWS that occur between lexical tokens in a
   structured field header are semantically interpreted as a single
   space character.

------------------------------------------------------------------------



More information about the Sm mailing list