Subject: Sequence of attributes in a SCRAM message

From: Tobias Markmann <[email-masked]>
Date: Mon, 15 Jun 2009 20:27:41 +0200

Hi,
>From Section 5.1 of the latest draft:

> Note that the order of attributes in client or server messages is
>    fixed, with the exception of extension attributes (described by the
>    "extensions" ABNF production), which can appear in any order in the
>    designated positions.  See the ABNF section for authoritative
>    reference.
>
>
Does this mean that during serialization, attribute 'a' goes first, then
'n', 'm', 'r' and so on? If so why the restriction on sequence?
Cheers,
Tobias Markmann

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Jun 2009 13:47:32 -0500

> 'n', 'm', 'r' and so on? If so why the restriction on sequence?

The ABNF itself provides the order.  See the ABNF.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 15 Jun 2009 20:28:20 +0100

> The ABNF itself provides the order.  See the ABNF.

That's not answering the question, though - what is the purpose of  
this rule? (I don't recall it existing before, except that 'r' was at  
the end).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Jun 2009 21:46:29 +0100

Tobias Markmann wrote:

>  Does this mean that during serialization, attribute 'a' goes first, 
> then 'n', 'm', 'r' and so on? If so why the restriction on sequence?

This restriction is to simplify implementations.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Jun 2009 15:56:20 -0500

> this rule? (I don't recall it existing before, except that 'r' was at  

Sorry.  See Jeff's reply about the GS2 header vs. the SCRAM messages --
at least that much order is required.  Within each of those order is not
crucial.  The GS2 header is simple enough that having order in it
actually simplifies things.

As for order within the SCRAM messages, I don't know the reason for nor
history of that, nor do I much care whether there's order in the SCRAM
messages.  But I agree that having order _and_ attribute=value adds
unnecessary redundance -- one could have order and no attribute=, or
attribute=value and no order, still have things work out.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Jun 2009 22:43:25 +0100

>actually simplifies things.
Right.

>attribute=value and no order, still have things work out.
This was discussed on the mailing list (before SCRAM became a GS2 
mechanism) and there were some arguments made for making the order fixed.
While I don't really care about the issue, I would rather not revisit 
it, unless people have good arguments while the fixed order is harmful.

(Also note that there is no order enforced on extensions.)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 16 Jun 2009 14:50:24 +0200

Nicolas Williams writes:
> As for order within the SCRAM messages, I don't know the reason for 
> nor history of that, nor do I much care whether there's order in the 
> SCRAM messages. But I agree that having order _and_ attribute=value 
> adds unnecessary redundance

As far as I can tell, the order is necessary for the computer. The a=v 
stuff makes scram messages easier to read for people, and it's only 
about eight bytes.

> -- one could have order and no attribute=, or attribute=value and no 
> order, still have things work out.

Yeah, but it would be more strain on the brain. 
x=43241,43214,4321423,,4321432,432 is harder to decipher than 
x=43214,y=34123,=4324132,w=,e=421. Perhaps not THAT much harder, but I 
think it's worth eight bytes.

Might be good to add a parenthetical remark, perhaps "this ordering 
simplifies some implementation aspects, e.g. the hash calculation".

Arnt

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Jun 2009 11:37:07 -0500

> stuff makes scram messages easier to read for people, and it's only 

It's possible to write a program that doesn't care about the order in
which the attrs appear.  That'd be programming 102 :)

> Yeah, but it would be more strain on the brain. 

We're having the age-old argument about redundancy.  How much redundancy
do we want in an on-the-wire encoding of a message?  ASN.1's BER's TLV
encodings have been problematic, in terms of bugs, meanwhile everyone is
always re-inventing PER and XML, which means that the debate never ends.

Let's not have this argument.  Instead let's agree that SCRAM is the way
it is and be done.  And keep in mind that several implementors have
prototypes already, or even code that awaits only consensus to get
deployed.  Changing SCRAM now for this little issue will cause those
implementors much hassle.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 16 Jun 2009 13:18:06 -0400

> which the attrs appear.  That'd be programming 102 :)

Right.  The ordering is necessary for the _protocol_, to a certain extent. 
Beyond that, it simplifies implementation but is not essential.

> implementors much hassle.

+1