[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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
>
>
>