Examples Are Somewhat Confusing

[Frank Dawson <fdawson@xxxxxxxxxxxxxxx>]

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