Request for comments: Sorting fields in signature generation

Johannes Ernst at
Wed Sep 27 18:10:20 UTC 2006

On Sep 27, 2006, at 9:48, Granqvist, Hans wrote:

> Johannes, just to clarify, are you against allowing
> multiple same-name params?

I don't like multi-valued fields, because in my experience, it is a  
slippery slope that usually leads somewhere one does not want to end  
up. It tends to go like this:

First iteration: we need a phone number, great, let's do:
     PhoneNumber: 123-456-7890

Second iteration: but this guy wants to give us an alternate phone  
number. Great, we have multi-valued fields, aren't we glad that we  
did this, so we simply can say:
     PhoneNumber: 123-456-7890, 234-567-8901

Third iteration: but he says that one of them is a daytime phone  
number, and the other an evening phone number. Darn! Now we got to  
kludge this in, because we have additional data related to one of the  
phone numbers that we now have to attach to, somehow, creating this  
bunch of happiness:
     PhoneNumber: 123-456-7890 (day), 234-567-8901 (evening)
(which requires additional parsing and breaks all previous  

Or this one:
     PhoneNumber: 123-456-7890 (day), 234-567-8901 (evening)
     CallingTimes: 9-5 (PhoneNumber[1]), 5-10 (PhoneNumber[2]))
(which requires us to come up with a way of naming one of the values  
of the multi-valued field -- which was the reason for the names in  
the name-value pair in the first place)

Or other contortions. If one does this a few times, one ends up like  
the famous cat-and-the-string picture ... in my experience, it leads  
to spaghetti data (like spaghetti code)

In my view, the correct way of representing any of this is as  
separate, first-class objects.

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
URL: <>
-------------- next part --------------

More information about the specs mailing list