One-pass signatures

G'day all.

The grammar in section 10.2 seems to suggest that multiple one-pass
signature packets should appear in reverse order to their corresponding
signature packets.

Which of the following "messages" are be syntactically valid?

    1) Suggested by the grammar in section 10.2 ("pure nesting"):

        <O-P Signature Packet #1>
        <O-P Signature Packet #2>
        <O-P Signature Packet #3>
        <Literal Data Packet>
        <Signature Packet #3>
        <Signature Packet #2>
        <Signature Packet #1>

    2) Common sense suggests that most implementations would produce:

        <O-P Signature Packet #1>
        <O-P Signature Packet #2>
        <O-P Signature Packet #3>
        <Literal Data Packet>
        <Signature Packet #1>
        <Signature Packet #2>
        <Signature Packet #3>

    3) If we're allowing a free-for-all on ordering:

        <O-P Signature Packet #1>
        <O-P Signature Packet #2>
        <O-P Signature Packet #3>
        <Literal Data Packet>
        <Signature Packet #1>
        <Signature Packet #3>
        <Signature Packet #2>

    4) Strictly grammatically correct under section 10.2, semantically
    dodgy:

        <O-P Signature Packet #1>
        <O-P Signature Packet #2>
        <Compressed Data Packet containing:
                <O-P Signature Packet #3>
                <Literal Data Packet>
                <Signature Packet #1>
        >
        <Signature Packet #3>
        <Signature Packet #2>

My suggestion is that 1, 2 and 3 all make sense and an implementation
should accept them.  The obvious way to allow 1, 2 and 3 (collect
signatures to be computed, compute them when you hit the literal data,
play "match-up" as you find the corresponding signature packets) would
also accept 4, so I'd be happy to say that a robust implmentation MUST
(SHOULD?) accept it.

That's for accepting messages.  What about producing them?

Cheers,
Andrew Bromage