RE: Examples Are Somewhat Confusing

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

Frank,

Actually, I was trying to focus on discussing the mime-dir draft (which
is not schema specific).  My examples are just that, random examples
illustrating various points.

According to the current mime-dir-02 draft, the following (schema
independent) are legal ways to represent a phone number in a schema.

>1. TEL; TYPE=HOME: 1-800-555-1234
>2. HOMEPHONE: 1-800-5555-1234
3. TEL; HOME, CELL: 1-800-555-1234
4. THIS-IS-JUST-AN-EXAMPLE: 1-800-555-1234

So I don't believe there is any problem representing a current v-card
phone number as a property in MIME-DIR.


>>> The other thing I wanted to propose on this topic is that it would be
>>> good to require that multi-valued properties be sequential in the
>>> mime-dir message body.  This would allow me to search for a property and
>>> end the search when I hit the last copy of the property rather than
>>> requiring that the entire body be parsed.  So this would be legal:
>
>This type of sequencing mandate for content is putting us on a very slippery 
>slope. I don't believe that this is very efficient or useful to a broad class
>of originating or receiving applications for this data. One should be able to
>sequence the properties within the body of such a content type as one finds 
>efficient or even convenient.  I don't agree with this type of limitation on 
>creating a data stream. I don't even understand how you will know that you
>have 
>"hit the last copy of the property" until you have parsed the complete
>content 
>information. This isn't a good idea to me.

The reason I proposed this was because if I am searching thru
properties, I must search thru all the properties in the body part to
determine if I have the complete set of TEL properties, instead of being
able to quit when I hit the last TEL property.  This saves time for a
linear search engine.  If you're searching thru a lot of items, this
savings will become a large additive time/resource savings.

I think I understand where you're coming from.  There may be v-card
backward compatibility issues here where some existing v-cards are in a
random order.  Also, I don't know if v-card encourages this, but if
people enter these manually, then that may be a problem too.

How about this.  When they're outside MIME-DIR, v-cards stay like they
are (random order).  When they get put inside a MIME-DIR body part, they
must be grouped, fixed-order.  Since MIME-DIR is not yet a standard,
nobody has code to put v-card in a MIME-DIR body part and we don't have
to worry about people re-implementing things.  The format is forward
compatible because all the old v-card reading code can handle random or
fixed order.

Does this make sense?

Thanks,
Alec.

>----------
>From: 	Frank Dawson[SMTP:fdawson@raleigh.ibm.com]
>Sent: 	Monday, August 26, 1996 6:20 AM
>To: 	ietf-asid; ietf-calendar
>Subject: 	Examples Are Somewhat Confusing
>
>Alec:
>
>I am somewhat confused by your examples...or at least not sure of the extent 
>they may imply in terms of your proposals.
>
>Are they meant to be another PROFILE type? They are not PROFILE=vCard based. 
>This is somewhat confusing. What is the complete gist of your discussions?
>Are 
>you also in this discussion proposing changes to the vCard profile? Are you 
>proposing yet another profile?
>
>You used the example:
>
>>> Common-Name; Language=de:  Burgermeister
>>> Common-Name; Language=en:  Burgerman
>
>This used type parameter construct (ie, "LANGUAGE=en)".  Why then did you not
>use the same construct on the telephone number (ie, 
>"TEL;TYPE=HOME:1-800-555-1234), when you used "HOMEPHONE:1-800-5555-1234"?
>This 
>was very confusing to allow type parameters on one type and not use it on 
>another. How would all the other characteristics of a telephone number be 
>specified. Hopefully, not with additional types (eg, not with WORKPHONE, 
>OTHERWORKPHONE, PREFERREDWORKPHONE, GSMCELLULARPHONE, CARPHONE, etc). 
>
>In addition, the minimal solution, with least astonishment appears to be that
>of specifying a property multiple times rather than a more complex grammar
>with 
>value field delimiters for multiple values (ie, not TEL:{800-555-1234; 
>800-999-9876} but rather TEL:800-555-1234 CRLF TEL:800-999-9876). This would 
>also apply to the case of multiple values for the formatted name or the 
>structured name properties.
>
>It would be good to make use one of the existing profiles for your examples,
>so 
>that the discussion is not clouded by the possible confusion with cross
>issues 
>such as this.
>
>You also proposed:
>
>>> The other thing I wanted to propose on this topic is that it would be
>>> good to require that multi-valued properties be sequential in the
>>> mime-dir message body.  This would allow me to search for a property and
>>> end the search when I hit the last copy of the property rather than
>>> requiring that the entire body be parsed.  So this would be legal:
>
>This type of sequencing mandate for content is putting us on a very slippery 
>slope. I don't believe that this is very efficient or useful to a broad class
>of originating or receiving applications for this data. One should be able to
>sequence the properties within the body of such a content type as one finds 
>efficient or even convenient.  I don't agree with this type of limitation on 
>creating a data stream. I don't even understand how you will know that you
>have 
>"hit the last copy of the property" until you have parsed the complete
>content 
>information. This isn't a good idea to me.
>
>Cheers.
>
>- - Frank Dawson
>
>  
>