RE: I've Got A Hammer...

["Alec Dun (Exchange)" <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

If you want the following data to interopreate with other apps:

>FOOTYPE:myname;me@host;OWNER;CONFIRMED
BARTYPE:date;date;date;date

...then you have to coordinate with others on the format of the data and
schema, right?  ...otherwise my app won't have a clue how to interpret
your data.  Ideally, the way to coordinate the format of the data and
schema with others is thru IETF or IANA.  During approval, the format of
the data needs to be explicitly layed out to ensure people know how to
send and interpret the data.

I think people defining a new property with a special datatype actually
would want to go out of your way to go thru IANA and IETF, if they are
interested in interoperating, right?

For those that don't care about interoperating with others, there is the
x-fooproptype, right?

All the properties in a schema must be strongly typed.

btw, do you realize that the way mime-dir-02 is defined today you'd have
to go thru IANA to get an additional v-card property added to a v-card
profile?  For example, if I wanted to add "BARTYPE:date;date;date;date"
to the v-card profile, I'd have to go thru IANA to add "BARTYPE".  If
you want to skip IANA, you'd have to make this
"x-BARTYPE:date;date;date;date".

Thanks,
Alec.

>----------
>From: 	Frank Dawson[SMTP:fdawson@raleigh.ibm.com]
>Sent: 	Monday, August 26, 1996 2:45 PM
>To: 	Alec Dun (Exchange)
>Cc: 	'Frank Dawson'; 'Harald.T.Alvestrand@uninett.no'; 'Tim Howes';
>'ietf-asid@umich.edu'; 'ietf-calendar@imc.org'
>Subject: 	I've Got A Hammer...
>
>Alec:
>
>The data typing seems to require that the type definitions (ie, new
>properties) 
>be cast as:
>
>1. One of these proprosed standardized data types (eg, INTEGER, FLOAT, etc),
>or 
>2. As a new registered data type (ie, via IANA processing), or 
>3. As a non-standard data type (eg, X-xyz-FOOTYPE). 
>
>This will make it somewhat cumbersome to define a new type such a structured
>or 
>multi-valued type (eg,  a property with the form of: 
>FOOTYPE:myname;me@host;OWNER;CONFIRMED or BARTYPE:date;date;date;date). 
>
>Now, most folks are just not going to go to the trouble of defining a new
>data 
>type with the IANA. This is a pain. They will also realize that the 
>non-standardized data types have a small hope in being accepted by 
>implementations. This leaves the low easier approach which is to use the 
>existing "nail" to solve the data representation problem.
>
>Who have we helped here? It seems to me we have just limited our data 
>definition capabilities. That is why data representation grammars go to the 
>lengths that they do to allow for constructed types. Now if we go down that 
>line of thinking, we are back to using NDL, ASN.1, Crocker's STIF, etc.  But,
>this does not seem like a low cost, low chat approach to this problem. In the
>"application/directory" domain we already have LDAP to address this.
>
>So...that is the thoughts behind my reference to the "nail" and "hammer".
>
>Cheers.
>
>- - Frank Dawson
>