Re: Identifying Multi-valued items

Quoteing [email protected], on Mon, Feb 03, 2003 at 12:43:43PM -0500:
> > Quoteing [email protected], on Fri, Jan 31, 2003 at 06:59:04PM -0500:
> > > Rfc2425 has this to say about multi-valued items:
> > > 
> > >    Each attribute defined in the text/directory body MAY have multiple
> > >    values, if allowed in the definition of the profile in which the
> > >    attribute is used. The general rule for encoding multi-valued items
> > >    is to simply create a new content line for each value (including the
> > >    type name).
> > > 
> > > Can someone please tell me how I can figure out which items are single 
> > > valued and which are multi-valued? 
> > 
> > Do you mean from reading the RFCs?
> 
> Yes. Rfc2425 which I quoted above describes the directory mime content 
> type and rfc2426 describes the vcard profile for the directory mime 
> content type -- and I'm trying to understand both documents.
> 
> Rfc2425 says attributes may have multiple values if the profile allows.
> 
> The profile rfc2426 appears to provide no restrictions on multiple
> values. (Every attribute is allowed multiple values.)

Technically, I think they may ONLY if explicitly allowed, and since  the
profile doesn't say anything, its not allowing it. So, you only get one
TEL field... I'm planning on ignoring that!

>  
> If an attribute like SORT-STRING occured more than once an application 
> would need to make a decision on which SORT-STRING value to use in order 
> to perform the sort.

Yes, perhaps the first?

> > On the decoding side, if you see multiple values, I guess its
> > multi-valued....
> 
> Is it true then that any parser that doesn't allow all attributes to 
> contain multiple values is in error? 

I don't know if its in error, I'd say the RFCs are in error, but I would
say its not robust. The rules about multi-value are obviously vague, and
even if they were specific, they would be broken occaisonally.

Cheers,
Sam