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

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

My 2 character example was not very good, especially considering the
crux of my argument is space-savings.

I do like John's proposal of enclosing the multiple values in { braces
}.

The only issue I see is how do we handle different modifiers on
multi-valued properties.  For example, in MIME-dir I can have:

Common-Name; Language=de:  Burgermeister
Common-Name; Language=en:  Burgerman
Common-Name; Language=en:  Burgerdude

If we go with the { braces } idea, would we do it this way?

Common-Name: { Language=de: Burgermeister, Language=en: Burgerman,
Language=en: Burgerdude }

...or would we only allow properties with the same attributes to be
repeated within the braces?

Common-Name; Language=de: Burgermeister
Common-Name; Language=en: { Burgerman, Burgerdude }



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:

HomePhone: 1-800-555-1234
Common-Name; Language=de:  Burgermeister
Common-Name; Language=en:  Burgerman

but this would not:

Common-Name; Language=de:  Burgermeister
HomePhone: 1-800-555-1234
Common-Name; Language=en:  Burgerman

Thanks,
Alec.

>----------
>From: 	Einar Stefferud[SMTP:Stef@nma.com]
>Sent: 	Friday, August 23, 1996 1:03 PM
>To: 	ietf-asid@umich.edu; ietf-calendar@imc.org
>Subject: 	Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt 
>
>I have always found, dating back to 1960, that storing or conveying
>attribute meaning via the absence of an explicit tag (or any other
>explicit clue) is a very bad idea, unless you are in a fully closed
>system and always know precisely what you are doing with every
>attribute and value.
>
>The Internet is NOT one of these closed systems!  Defaulting must be
>done with extreme care in the Internet, if it is done at all.  So, I
>endorse John suggestion to use a multi-valued attribute in place of a
>sequence (or set, or list) of individual attributes that use absence
>defaulting for all but the first of these line-separated attributes.
>
>Indeed, one breakthrough aspect of ASID-DIR and ASID-vCARD is exactly
>this concept of multivaluesd attributes with convenient and short
>sub-attribute tagging within multi valued attributes.
>
>In Internet Standards, this becomes excrutiating.  Look at the
>problems we now have with MIME CHARSET as a prime example of what
>comes of "efficiencies" like omission of tags, such that default
>meaning is attributed to absence of explicit tags.
>
>Alec is saving 2 characters per attribute.  May I ask what Alec is
>going to do with these savings?  We may have already spent the next
>ten years of accumulated savings in this brief discussion.  And who is
>going to pay for all the extra software effort required to achieve his
>saving, and for all the confusion that is likely to follow as this
>technology continues to be extended?
>
>For my money, it has to be a lot easier to deal with a set of names
>that are being defined as equivalent to each other by putting them all
>in one well labeled attribute.  Now I have no need to be concerned
>with all those implied inter-attribute relationships
>
>Cheers...\Stef
>
>From Klensin's message Fri, 23 Aug 1996 03:28:48 -0400 (EDT):
>}
>}
>}On Thu, 22 Aug 1996 18:25:53 -0700  "Alec Dun (Exchange)" 
>}<AlecDu@Exchange.Microsoft.com> wrote:
>}>...
>}> 2.  Efficiency in repeated properties.  To increase efficiency, I
>}> propose that we allow properties which have the same name to be repeated
>}> without the name.  In this scheme, the repeated property would inherit
>}> the attributes from the previous property.  For example:
>}> 
>}> CN:  Frank Arthur
>}> CN:  Arthur Frank
>}> CN:  Frank
>}> 
>}> would become
>}> 
>}> CN:  Frank Arthur
>}> :Arthur Frank
>}> :Frank
>}
>}Alec,
>}
>}From a language design standpoint, I'd recommend against this, 
>}at least in this form.  It has some slightly uncomfortable 
>}parsing properties relative for environments in which one might 
>}want to implement things by, e.g., quickly sweeping through the 
>}file using a hash on the names to insert properties in a list.  
>}More generally, one doesn't want to need to look ahead and then 
>}back up if that is avoidable.  Doing things with omitted 
>}property tags implies that one needs strong ordering rules and, 
>}typically, an extra algorithmic step to guard against bad 
>}behavior from violations of those rules.  One can avoid those 
>}problems by a careful choice of parsing procedures, but we try 
>}to avoid imposing that type of constraint unless it is clearly 
>}needed.
>}
>}As an alternative, if you want to omit repeated property names, 
>}consider introducing an iterated list, e.g.,
>}   CN: { Frank Arthur, Arthur Frank,
>}                Frank }
>}in C-ish style or
>}    <CN> Frank Arthur, Arthur Frank, Frank </CN>
>}if HTML-ish style.
>}
>}I'll not comment on the other two suggestions at this time.
>}
>}    john
>}
>}
>}
>}
>