Gorry Fairhurst wrote:
- It is not reasonable to restrict Listen packets to carry no
options. A use may be found for Listen options one day. It suffices
to say that Listen packets are currently ignored. This includes any
options on Listen packets.
My understanding was that the suggested outcome of the last IETF was
that Options were allowed - but were not defined. This allowed some
subsequent evolution of the method if this were to be needed and text
was suggested to this effect (I think by Colin). If you think the text
says different, please do let us know.
The current text says that Data Offset is 0. I assumed you meant 20, which
prohibits options altogether by eliminating any space for them. The text also
says that options MUST be ignored. This is different from prohibiting them
and better. But I would not prohibit them and I would not say they MUST be
ignored. I would simply demonstrate via pseudocode that DCCP-Listen packets
are ignored by endpoints as a whole.
- "MUST NOT carry payload data" => No other DCCP packet has this
restriction. Simply say, as for the other packet types, that payload
data is ignored.
This was discussed at the last two IETF meetings, and the thinking at
the time was since the packet contained no sequence number (because the
protocol machine has not yet reached this stage), it could not be used
to carry data.
Like I said, payload data will be ignored.
RFC4340 section 5 intro:
The application data area follows the header. In some
packet types, this area contains data for the application; in other
packet types, its contents are ignored.
Please see also RFC4340's definitions of DCCP-Ack, DCCP-Sync, DCCP-SyncAck,
DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets, none of which carry
application data, but all of which allow a nonempty application data area.
This kind of arbitrary departure from previously established RFC semantics is
disappointing and another reason the document does not feel quite ready yet.
It should probably include new pseudocode, additions and modifications
to RFC4340 Section 8.5, handling INVITED state and the receipt of
Listen packets.
Need to think.
From previous experience I will just say that without explicit and thought
through pseudocode it is extremely likely state machine errors will be introduced.
Eddie
