Thanks Eddie, this is really valuable, more replies in-line.
Eddie Kohler wrote:
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.
>
Yes, that was my mistake. It will be fixed as requested (>=5).
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.
>
Yes, as written, DCCP-Listen is always discarded by the client (and
often by the net). Magnus's suggestion would allow it to optionally
first trigger an action (resend Request) - to be discussed by the group.
I would simply demonstrate via pseudocode
that DCCP-Listen packets are ignored by endpoints as a whole.
I think that would be the right thing to write in the pseudocode.
- "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.
So, this is the same processing as option fields in the DCCP-Listen case.
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.
That could be fine. The reasons why we thought it was bad for the data
payload to be used by the client were the lack of sequence numbers,
undetermined CCID, options, etc. - are you saying this is actually OK?
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.
Right.
This kind of arbitrary departure from previously established RFC
semantics is disappointing and another reason the document does not feel
quite ready yet.
Given two options, I prefer consistency, if your judgment is that it's
safe to allow the data field, I'd be happy to put this to the WG.
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.
If there were offers of a volunteer to suggest/work together on
pseudocode, I'd be really interested....
Eddie
Gorry
