IFX Mail Archive: IFX> Using CONNEG with IPPFAX

IFX Mail Archive: IFX> Using CONNEG with IPPFAX

IFX> Using CONNEG with IPPFAX

From: John Pulera (jpulera@minolta-mil.com)
Date: Tue Jan 29 2002 - 20:24:58 EST

  • Next message: John Pulera: "IFX> UIF spec has been updated: 'uif-spec-09'"

    Per my action item from the last meeting, I checked with Graham Klyne (main
    author of the CONNEG-related RFCs) on the syntactical validity of section
    A.1.2 and its subsections in the UIF Specification. Although we'll be able
    to define "auxiliary predicate" values (e.g., "profile-uif-f" or
    "profile-uif-cg"), we won't be able to use them to add on incremental
    features like the following:

    (| (profile-uif-s)
       (& (profile-uif-f])
           (dpi=[200,300,600,1200]) )
       (& (profile-uif-c)
           (dpi=[200,300,600]) ) )

    to indicate optional support of 1200 dpi for UIF Profile F and optional 600
    dpi for UIF Profile C. He made a couple of suggestions:

    (1) If the goal is to shorten the length of the CONNEG expression, then he
    suggested we use the hash-based approach described in RFC2938 (for which
    there is a freely available Java implementation at the IMC website:
    http://www.imc.org/ietf-medfree/index.html). The disadvantage here, however,
    is capabilities advertised in the CONNEG expressions would no longer be
    "human-readable". See some examples here:

    (2) If human readability is desired, then, alternatively, we can exclude
    frequently varied parameters (e.g., resolution) from the minimum CONNEG
    strings specified in section A.1.2.1 of the UIF spec. If we did this, then
    the CONNEG expression shown earlier would be valid. But, in this case, how
    many parameters should be excluded from the minimum CONNEG strings &
    separately specified in the CONNEG expression? Where would we draw the line?

    Do I here preferences for either alternatives 1 or 2? Or should we just go
    back to using the whole expression since we've already taken into account
    really long values for the 'uif-profile-capabilities' IPP attribute by using
    1setOf text(MAX)?

    Graham Klyne's response is attached.

    John P


    attached mail follows:


    John,

    The media feature mechanism specified to achieve the effect you describe is
    in RFC 2938 -- this uses the "auxiliary predicate" syntax of RFC 2533 in
    conjunction with an MD5 hash to generate an identifier for the composite of
    media features. The main advantage of this approach is that you can
    introduce new, verifiable composite values without having to update on a
    central definition. There is an implementation of this, in Java, on the
    IMC web site (linked from the conneg/medfree working group page there).

    You may feel this is hash-based approach is not so friendly if humans ever
    need to read the identifiers. If so, another approach I would recommend is
    to use the auxiliary predicate syntax rather than introduce a new tag; e.g.

       (ipp-profile-uif-s)
       (ipp-profile-uif-f)
       (ipp-profile-uif-j)
       (ipp-profile-uif-cg)
       (ipp-profile-uif-c)
       (ipp-profile-uif-lg)
       (ipp-profile-uif-l)

    defined as below.

    Then you could write something like:

    (| (ipp-profile-uif-s)
        (ipp-profile-uif-c)
        (& (image-file-structure=TIFF-MRC-limited)
           (MRC-mode=1)
           (MRC-max-stripe-size<=256)
           (dpi=[200,300]) ) )

    >Then, for example, we can rewrite the minimum capabilities string for UIF
    >Profile M shown in Section A1.1.6 of the D0.8 version of the UIF spec as
    >
    >(| (profile=[uif-s,uif-c])
    > (& (image-file-structure=TIFF-MRC-limited)
    > (MRC-mode=1)
    > (MRC-max-stripe-size<=256)
    > (profile=[uif-s,uif-c])
    > (dpi=[200,300]) ) )

    I'm not sure why you use (profile ...) inside the (& ... ). I think it
    will not give a useful effect. See version above.

    >As another example, if we would like to advertise a Receiver that can
    >support UIF Profiles S and F with optional resolution of 1200 dpi and can
    >support UIF Profile C with the optional resolution of 600dpi, we can say
    >(| (& (profile=[uif-s,uif-f])
    > (dpi=[200,300,600,1200]) )
    > (& (profile=uif-c)
    > (dpi=[200,300,600]) ) )

    The feature expression processing logic doesn't operate support
    combinations to *extend* the range of resolutions in this way. Take the
    profile-uif-c case: that profile specified (dpi=[200,300]) -- AND-ing that
    with (dpi=[200,300,600]) will leave you back where you started; i.e. with
    (dpi=[200,300]). OR-ing the desired extra values doesn't work in this case
    .. since they wouldn't be bound to be used with the other features of that
    profile.

    I can suggest a couple of approaches:

    (1) for frequently varied parameters, don't mention them at all in the
    profile specification. Then:
         (& (ipp-profile-uif-c) (dpi=[200,300,600]) )
    would have the desired effect.

    (2) mention a maximal set of resolution options -- if you don't mention
    resolution separately, this is what you get, but if you restrict the
    options (per example above) you get the intersection of specified values.

    #g

    --------------------------
            __
           /\ \ Graham Klyne
          / \ \ (GK@ACM.ORG)
         / /\ \ \
        / / /\ \ \
       / / /__\_\ \
      / / /________\
      \/___________/



    This archive was generated by hypermail 2b29 : Tue Jan 29 2002 - 20:22:49 EST