[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt
Frank,
The datatype parameter is optional.
New datatypes can be defined using IANA or X-.
The analogy of a "making every problem look like a nail to a hammer"
could be applied to almost any internet standard. For example: RFC
1521 defines the definition/syntax of a mime body part which makes all
body parts look like a nail to a MIME body-part parser (hammer).
Another example: v-card defines a generic way to represent a contact,
all v-card contacts look like nails to a v-card contact parser (hammer).
Although I understand the nail/hammer anology, I'm unclear why you think
pushing for standards (definitions of nails and how hammers should hit
them) is a bad thing.
If you have a specific need, just say what it is so your needs for the
shape of the nail/hammer can be accomodated by the working group.
Thanks,
Alec.
>----------
>From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com]
>Sent: Monday, August 26, 1996 6:05 AM
>To: Alec Dun (Exchange)
>Cc: 'Harald.T.Alvestrand@uninett.no'; 'Tim Howes'; 'ietf-asid@umich.edu';
>'ietf-calendar@imc.org'
>Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt
>
>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
>>
>>
>>
>
>
>
>
>