[standards-jig] JEP-0017: Naive Packet Framing Protocol
mikelin at MIT.EDU
Wed Jan 30 17:53:26 UTC 2002
As I see it, the issues you are pointing out are more verbose forms of
the ones listed in the JEP as it is.
> 1. I cannot think of a way to protect against misframing (number not
> representing the full packet, representing more than one packet) other
> than by trusting the remote party to indicate framing correctly. This
> would seem to indicate that you must have a degree of trust of the
> remote party to trust their framing, so client to server and server to
> server connections are out of bounds - this could only be used within a
> particular server architecture.
Firstly, there is already this sort of trust in place to send
Secondly, as stated in the JEP, error-handling semantics in the event of
misframing would have to be arbitrarily defined in a future revision of
the JEP. However, I think it would be difficult to build any kind of DoS
attack around misframing that would be more effective than can be done
currently. If the packet is misframed, it wil probably not be a
well-formed XML fragment, so parsing should fail at some point (although
possibly not until the end of the route).
> There is also routing information associated with a user's session,
> which replaces the 'from' address with the correct one for the session,
> and adds a 'to' address if none was specified (to a user's account.)
I don't quite understand this. Can you clarify?
> 2. If namespaces were properly handled by Jabber, this would mean that
> there was other data outside of a packet which was required for correct
> handling of the packet, being the namespaces and prefixes declared on
> the root element. This sort of framing and full use of namespaces seem
> to be mutually exclusive - you would either need to rewrite packets to
> contain all namespaces they need as defined by the document representing
> the connection between the packets, or ignore namespaces declared at the
Namespaces are handled correctly by Jabber.
>From an XML parsing perspective, the framing data is not required for
correct handling of the packet; it's just extraneous data. So I think
the namespace issue for the text nodes is generally moot. The framing
data is just sugar for the transport layer. So, as stated in the JEP,
there is a valid concern that the transport metadata is being sort of
mixed with its payload content - but this seems necessary for the sake
of backwards compatibility.
More information about the Standards