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

[Einar Stefferud <Stef@xxxxxxx>]

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