Subject: Re: draft-ietf-conneg-media-features-02.txt; LAST CALL

From: Graham Klyne <[email-masked]>
Date: Wed, 18 Nov 1998 16:03:24 +0000

At 18:36 17/11/98 +0100, Koen Holtman wrote:

>Graham Klyne:
>[...]  
>>A "compromise" way out of this would be to define both pixel- and
>>phyisical- dimensions, and allow an application to choose what it
>>uses.  But I would prefer to find a consensus that satisfies our
>>various desiderata without creating duplicate ways to express the
>>same feature set.
>
>I would prefer this "compromise" of having all three over having just
>two, even if having just two can be made to work (and we have seen
>that this is not easy).  In the web scenarios I have in mind, having
>all three would be easier on content authors: they can always use the
>tags which most naturally describe their content.

For the time being, this seems the way to go.

Based on the small feedback I have had, there does seem to be a significant
constituency for retaining pixel measures.  But I do still believe there
will be situations where they do not work well.

>One could argue that having three tags which are non-orthogonal would
>be more difficult on negotiation protocols.  However, if you are going
>to make an extensible negotiation protocol coupled to an essentially
>open registry like the feature tag registry, you will have to deal
>with non-orthogonality anyway, because sometime, probably very soon,
>someone is going to register a tag that is non-orthogonal to other
>existing tags.

In the current version, there is no way to deal with non-orthogonality
_within_ the capability description framework.  Such mechanisms were
deliberately excluded in the interests of simplicity, and ensuring a
tractable feature matching algorithm.  It may be that future developments
will address this issue, but I'm not assuming that will be so.

External ad-hoc measures can be employed, and I expect that
application-specific schema will play a part here.

>Now, in the case of fax negotiation, maybe orthogonality of tags
>(which implies that any feature set can be expressed in only one way)
>is more desirable than extensibility of the tag set by an open
>process.  But in that case I would argue that fax negotiation should
>not focus on the initial set of features for the feature tag registry
>created by the conneg group.  In that case the fax group should define
>a closed `fax feature set', with very strict rules for extensibility.
>Of course the resulting fax tags should be put in the more open conneg
>registry too, but that is besides the point.

This goes against the goal of a common application-independent vocabulary,
which can help to promote cross-application exchanges.

In the short term, creating a framework that can be adopted and adapted on
an application-by-application basis is clearly most important.  But I would
prefer to be working towards bridging rather than Balkanizing applications.

I am coming to a view that if we have a common framework, and some
commonality of feature tags, then this is a significant step in the right
direction.  It's not perfect in all respects, and there would likely be
some need for ad-hoc feature processing when moving data across application
boundaries, but I can see that task would be much easier than might
otherwise be the case. 

>On a historical note: The MIME type namespace used to be a fairly
>closed one, in that it was difficult to add a new type unless it was
>fundamentally different from other types.  This closedness was the
>best way to go for e-mail, the intended application for MIME.  Some
>believe however that re-using the closed MIME namespace for the web
>significantly hurt the web, for example because the closedness blocked
>one easy route to sub-negotiation on HTML versions.

It sounds like a classic trade-off between stardardization and progress.

Without denying the possible hurt, I would suggest that there are also
benefits as MIME becomes established as a framework for data encapsulation
that can work across applications.

>The point is that different negotiation protocols (like web and fax
>negotiation) could end up hurting each other if they share the same
>registration procedure while they really need different ones.  I don't
>know enough about fax to tell if there is a real need for a procedure
>more restrictive than the one envisaged for the web, but this is
>something we need to find out before we proceed with a single
>procedure.  A shared namespace is always good, but maybe getting a
>`web seal of approval' on a tag should be a different procedure from
>getting a 'fax seal of approval'.

I don't think that the difference, if any, lies along the "web vs fax"
axis, but with what happens to the data when it reaches a user's system.
The image size debate has been largely about how a received image is
rendered, not the mechanism used for its transfer.

An indication of this is the proposal to use IPP (hence HTTP) as a
mechanism for session mode fax.  If WWW and e-mail did not share a common
content-type name space, I think this would be a far more difficult path to
tread.

So, I conclude:  if there are genuine differences then by all means allow
registrations for different applications to deal with the information that
they need.  But I also think that it's worth putting in some effort to
avoid gratuitous diversity.  (I guess this is the fundamental tension in
all registration spaces.)

#g

------------
Graham Klyne
([email-masked])

---

From: Al Gilman <[email-masked]>
Date: Wed, 18 Nov 1998 12:00:19 -0500 (EST)

to follow up on what Graham Klyne said:

> application-specific schema[ta] will play a part here.

This is what I have been trying to warn about.  The registration
facility lacks the tools to enforce orthogonality, and even a
plan for how to bind the wounds.  There needs to be sufficient
means for a third registration to delare relations (assertions,
cross-propositions) which bind tokens introduced in first- and
second- un-coordinated registrations.

The present drafts, as I vaguely understand them, lay no
foundations for this but allow annexes in registrations so that
there can be an after-the-fact rationalization across diverse
registrations.

In other words, if I submit a registration with some new terms
that includes a schema documenting the relationship of these
terms to earlier-registered terms, the registry will house but
not comprehend the relationships asserted in the schema.

Al

---

From: Ted Hardie <[email-masked]>
Date: Wed, 18 Nov 1998 16:27:11 -0800 (PST)

Al,
	There are several different trees in the
registration, and these have different characteristics
in regards to the kinds of registration you describe.
For proposals in the IETF tree, the IESG is responsible
for making sure that proposed registrations are needed
and have some appropriate relation to existing registrations
(orthoganal, superset, etc.).  In the Global tree, there
will be expert review of the registrations for similar
purposes.  Either the IESG or the area expert may request
that a registrant insert explanatory text in the registration,
in order to guide implementors.  The URL tree is completely
open, and the only guarantee there is that the tags are
globally unique.  There may well be instances where interoperable
or identical features get the different URL tags--avoiding
that problem is one reason to go to the more stringent trees
	The registry does not, as you note, comprehend the
relationships among the features.  That's not really its job;
its job is to make sure that there is a single place to go when
you want information about a feature.  Currently, there is
a uni-directional reference (A registration can tell you which
other registrations it references, but not which registrations
reference it).  More fully featured cross-referencing may well
be needed in time, but that still won't be putting more intelligence
in the registry--just providing another tool for implementors.
	Creating a registry with the intelligence to enforce
orthogonality and bind the wounds of non-orthogonal features
isn't in the charter of the group--we're relying on the IESG,
the area experts, and the implementors to provide that intelligence.
It's a low tech solution, but it has worked in the past.
			best regards,
				Ted Hardie
				[email-masked]

---

From: [email-masked] (Koen Holtman)
Date: Tue, 24 Nov 1998 19:12:03 +0100 (MET)

[Sorry for the late reply -- I misfiled your message before reading it]

>At 18:36 17/11/98 +0100, Koen Holtman wrote:
[....]
>_within_ the capability description framework.  

I think you are underestimating the framework.  For one thing I don't
think there would be any trouble in it dealing with the
inches/pixels/dpi non-orthogonality, provided that one of the two
parties in the negotiation process knows about all three of these tags
(and the party which renders the content generally will know about all
three).  pix-x and pix-y are also somewhat non-orthogonal (in a
different way) and the framework can deal with that too.

Am I missing something?

It is true of course that non-orthogonality does prevent certain types
of simplifications in the framework.  I always thought that you wanted
non-othogonality to allow for (fax) negotiation protocols which are
much simpler than the framework.

[...]
>rendered, not the mechanism used for its transfer.

I was simplifying a bit above: with 'fax' I meant negotiation for
fax-type devices and with 'web' negotiation for web browser type
devices.  I agree that the transport is largely irrelevant.

>#g

Koen.

---

From: [email-masked] (Koen Holtman)
Date: Tue, 24 Nov 1998 19:30:06 +0100 (MET)

Ted Hardie:
[...]
>It's a low tech solution, but it has worked in the past.

I'm confused by the above.  Are you saying that we

 a) want the IESG and experts to enforce orthogonality in their parts
    of the namespace

or

 b) want the IESG and experts to document non-orthogonality in their
    parts of the namespace, if it is created, so that implementers can
    provide the intelligence to handle it?

As far as I can see the two are mutually exclusive. 

From my past messages it should be obvious that I want option
b). Though of course gratuitous non-orthogonality should be avoided,
there are cases where adding non-orthogonality will be the best
choice.

I am not sure that all other people in the WG want b) too.

Koen.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 24 Nov 1998 15:01:15 -0800 (PST)

Koen,
	I don't personally believe that all registrations
will be completely orthogonal to all other registrations;
they may well have other relations (like supersetting) which
make sense.  For the URL registrations, that relationship
is opaque within the context of the registry (it may be
widely disseminated in some other forum, but it doesn't
appear in the registry).  For the Area expert registrations,
I believe that the area expert and related mailing list
may well ask questions like "Isn't your g.foo the same as his
g.bar?" and ask that the answers and reasoning be made part
of the registration.  That, as I see it, is "binding the
wounds" of features where a truly strict system would insist
that one feature be dropped because it could be derived
from two or more other features.
	I leave the working of the IESG as an excercise
for the reader.
		regards,
			Ted Hardie
			[email-masked]