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