ietf-822
[Top] [All Lists]

Re: Re: POINT OF ORDER - multiple types

1991-09-18 10:43:36
From: "Alain FONTAINE (Postmaster - NAD)" 
<fontaine(_at_)sri(_dot_)ucl(_dot_)ac(_dot_)be>

This question of types/subtypes is maddening me. ...
... Content-type should contain a single integer.
The assigned numbers RFC should list a table of the real meanings. After
all, when I see 'image/FRDT', what good does it do to me if I have an
image display, but no 'FDRT' decoder ????                    /AF

First thought is: NO!!

After all.. having a *named* description allows an end user who may not
have a copy of the mapping table to make an intelligent guess as to what
the body part may be.  This is the point of clearly marking the data as
to what it is, to give the customers the ability to intelligently deal
with it.  Otherwise they are reduced to simplistic guesswork to figure
out what to do with the body parts, a task they are likely to fail at.
But then a thought occurred:  Not all the customers speak English.  What
is the word for "image" in French or Japanese or etc?  Not all the descriptions
are in English, G3FAX certainly isn't.  But all the `root' descriptions are ...

However a UA for foriegners (er, non-USers) (er, non-English-speakers) should
likely include a mapping table which produces descriptions in the users
native language.  Whether the input to the table is a number or a word
doesn't really make any difference, both are valid identifiers especially
if controlled by an identifier-czar of some sort.

A single layer of `types' is too simplistic, IMO.  When I was reading
the last draft, two-layer system described there `seemed' to be too
simplistic.  The lesson I take from the naming of Internet hosts is
that a fixed number of layers was not enough.  The administrative setup
outgrew 1 layer, so it was made 2.  That was outgrown & we've gone to 
the current distributedly controlled n-level we currently have.

Suppose, for instance, that I dream up a hundred different things to
transport in e-mail, things which our customers want to transport.  Does
it make sense to go to the number-czar for body part descriptions for
each one?  Or is it easier & simpler to get h{im,er} to assign 
"vendor / TWG" as a second level description under which I can put anything?

The ISO people also have a multi level naming hierarchy.  It is based
off of numbers, but there is a mapping from number -> name defined.

My answer is still `NO!!' .. we need a hierarchical system for describing
body parts.  My concern is completely opposite.  Rather than wondering
if two levels are too many, I wonder if two levels are enough.

        David

<Prev in Thread] Current Thread [Next in Thread>