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

[Frank Dawson <fdawson@xxxxxxxxxxxxxxx>]

Alex:

One of my concerns with this generic approach is that it makes every problem 
look like a "nail"; 'cause what you have as a tool is a "hammer".

If I only have INTEGER, STRING, FLOAT, CURRENCY, DATETIME data types, then we 
are inclined by the constraints to solve our problem using these elementary 
types rather than the natural object types of the problem domain (ie, all 
problems look like a "nail" problem).

This is not to say that adding a DATATYPE type parameter does not make some 
sense. It just should not be mandated.

The other concern is that MIME content types are now being used outside of a 
MIME email transport environment. This is great! However, it also places 
additional design considerations on our work. All problems are not just solved 
by a "hammer" or in this case an email solution domain.

Cheers.

- - Frank Dawson





To: Harald.T.Alvestrand @ uninett.no ("'Harald.T.Alvestrand@uninett.no'") @ 
RTPSMTP
cc: howes @ netscape.com ("'Tim Howes'") @ RTPSMTP, ietf-asid @ umich.edu 
("'ietf-asid@umich.edu'") @ RTPSMTP, ietf-calendar @ imc.org 
("'ietf-calendar@imc.org'") @ RTPSMTP (bcc: Frank Dawson)
From: AlecDu @ exchange.microsoft.com ("Alec Dun (Exchange)") @ RTPSMTP
Date: 08/23/96 01:22:34 PM
Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt
Security: 

On the datatypes issue:  the key reason I want the datatype parameter is
to enable generic property handling code to be written.

For example, imagine that I have a bunch of messages containing mime-dir
body parts.  Now I want to write a generic piece of code that searches
for items where a specified property (for example meetingdate) has Date
> 1 Aug 96 and Date < 31 Aug 96 in each message.  I could write the
search code one of two ways.

a.  I could have the search code implicitly understand every field, what
it means, and how to interpret it.  If new profiles and fields get
defined, I need to modify the code to be able to do the search.

b.  I could have generic search code that only needs to understand how
to do comparisons on a given datatype.  If new fields get defined, I
don't need to modify the search code at all.

>How would I interpret sensibly
>
>CN;datatype=currency: NOK
>CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif

I would expect CN to always be of datatype=text.  The added value of
clearly identifying the datatype=text is that you allow
serach/sort/storage/etc code to handle the property generically without
having to special-case the type of each property.



On the grouping issue, I'm not so worried about the simple case that you
point out, but what if there are a lot of parameters on the body part
header?  Is the "Content-Type:" optional?

>--xx
>app/dir;profile=meetingdetails
>
>Location; datatype=text:  "At the boathose"
>Date; datatype=date: 11 Aug 96
>Time; datatype=time: 10:30:00

could look like:

>--xx
Content-Type: application/directory; charset=iso-8859-1; 
>                    language=german; profile=meetingdetails
>
>Location; datatype=text:  "At the boathose"
>Date; datatype=date: 11 Aug 96
>Time; datatype=time: 10:30:00


Also, what do you think about "properties/<x>" (ie.
"properties/directory" and "properties/appointment") as a top level mime
type?

Thanks,
Alec.

>----------
>From:  Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no]
>Sent:  Friday, August 23, 1996 5:02 AM
>To:  Alec Dun (Exchange)
>Cc:  'Tim Howes'; 'ietf-asid@umich.edu'; 'ietf-calendar@imc.org'
>Subject:  Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt
>
>Alec,
>
>I think datatypes need to be part of the attribute definition, not of
>the attribute value.
>
>How would I interpret sensibly
>
>CN;datatype=currency: NOK
>CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif
>
>when I want to put the CN into a mailing list?
>
>The grouping needs more thought - your example of a meeting with
>attendees is one example of use of this. But I think the overhead
>compared to a bunch of separate MIME objects is actually quite low;
>you save about 1 line per object.
>
>Your example:
>
>begin:  meetingdetails
>Location; datatype=text:  "At the boathose"
>Date; datatype=date: 11 Aug 96
>Time; datatype=time: 10:30:00
>begin:  meetingattendee
>CN:  Frank Arthur
>SN:  Jones
>Status:  Required
>begin:  meetingattendee
>CN:  James George
>SN:  Brown
>Status:  Optional
>
>becomes
>
>--xx
>app/dir;profile=meetingdetails
>
>Location; datatype=text:  "At the boathose"
>Date; datatype=date: 11 Aug 96
>Time; datatype=time: 10:30:00
>--xx
>app/dir;profile=meetingattendee
>
>CN:  Frank Arthur
>SN:  Jones
>Status: Required
>--xx
>app/dir;profile=meetingattendee
>
>CN:  James George
>SN:  Brown
>Status:  Optional
>--xx--
>
>Not a world of difference; think about whether we want the additional
>complexity in one parser, rather than having two of them.
>(I left out the links; not sure we need them)
>
>             Harald A
>
>
>