RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt

["Roland H. Alden" <ralden@xxxxxxxxxx>]

>Harald.T.Alvestrand wrote:
>
>I think datatypes need to be part of the attribute definition, not of
>the attribute value.
>

I would tend to agree although I think I know where 
this idea is coming from, searching.

If property foo is defined in spec n.n to be a time 
value then any implementation written to n.n can
know the type of foo without further ado. The question
is, when someone extends the spec with property
x-bar with a time value. How interesting is it for
software which does not understand *what* x-bar 'is'
to manipulate its value?

In the case of searching on behalf of a human client
one can make an argument that it is useful. The human
query "give me all records where time = xxx"
might result in some silly matches, such as

   x-time-I-think-the-cookies-will-be-served-at-this-mtg: 14:15:00 -0800
 

that may or may not be useful to a human. Certainly the hit 
is of little value to a deterministic process which has no 
business fooling with data for which it has no understanding 
of the semantics.

There is also the matter of representation. If I understand 
the type of

   x-time-I-think-the-cookies-will-be-served-at-this-mtg

then I can store its value in a different, possibly more compact
form, even if I don't understand what it means. If I don't
understand the type I basically must commit to storing the whole
property string. The question is, how valuable is it for an
implementation to internalize properties which it cannot use?
For an endpoint I think there is not much value, for an
intermediate node which passes the data along, it's important.
But of course it would probably be best to pass it along in
original form too and not try to "internalize" and "regenerate"
it.

Another important application of typing is properties that
have values that can usefully be of several types. For 
instance:

   photo ; [gif | jpeg | tiff] : <value>

Unless <value> is always self-describing it is useful to have
some sugar to pass along information on how the value has
been represented.

In vCard we have proposed combining representation choices
with type choices in this way. For example:

   photo; base64; gif : <value in base64>

While it might be consider "impure" to have made "type" and 
"representation" into "syntactic equals", as a practical matter
software tends to need both or neither if it is going to
do something useful with the value.

Certainly type information is going to be needed unless all
values are of only one type! So the issue becomes how to 
communicate it. I think that issue divides neatly into
whether it is always expressed (the subtext of Alec Dun's
post) or whether "defaulting" can be used to eliminate
some of the verboseness of the average transaction.

Personally I think that some syntax for communicating
type and representation is clearly a requirement. At the
same time, I think there is no reason that well-defined
properties (i.e, those mentioned in version 1.0 of a spec)
can't have "well-defined" default (implied) types and
probably even *rules* on the allowable set of types. For
example:

   full-name : <is a string value but can be any charset)

is reasonable, whereas

   full-name; gif : <is a gif image>

might be syntactically allowable but disallowed because
it upsets everyone's expectation on the types of computations
they plan to do with "full-name".

In other words, a fully flexible "mix and match" syntax
will lead to a combinatorial explosion of useless productions,
so a spec will wind up fixing some constrains on allowed
types in certian contexts anyway; the syntax might as well
benefit from those constraints.

To close let me point out one problematic case. That where
the value is a "pointer" such as:

   foo; url : http://www.foo.com/bar/gag

Where it is HTTP that will return the "type" information for the
object http://www.foo.com/bar/gag. The syntax might allow:

   photo; gif: http://www.foo.com/me.jpg

Where 'gif' advised the the dereferencer of the url to expect a
gif but, in fact, anything could come back from the http server
(the same holds true for a 'local' reference to another MIME
part). 

My point is that in the above example the syntax provides for two
sources of potentially conflicting type information. It might be
reasonable then to literally prohibit type information for
URL or content-ID values on the grounds that the client
should follow the pointers and use other type discovery
mechanisms.

-Roland