There are three (soon four) versions of TLS, each with its own RFC (plus a retrospective historical one for SSLv3), but at the basic record level for unencrypted records -- which is, initial handshake records through first CCS or alert -- they are the same.
RFC5246 for TLSv1.2 in the section on ClientHello defines at the top of page 41 that structure (ClientHello) to include
SessionID session_id. Similarly for ServerHello at the bottom of page 42. Note that HelloRequest is also classified as a hello message (and a handshake message) but does not contain a session_id or indeed any body at all.
SessionID is defined on page 40 as
You should recognize that syntax as a variable-length vector previously explained in 4.3 which also explains how the length prefix of every variable-length vector works.
'Empty' means no bytes in the value i.e. a length of zero, encoded as a length prefix of zero followed by no (or equivalently not any) content. If you think about the encodings defined in section 4 it is obvious that you cannot omit a field from a fixed structure; some (not all) variable-length fields can be empty, and some (only some) structures have variants where you use only the fields of the one variant applicable in a given situation as specified. However, the extension field in Client or Server Hello is defined as a variable-length sequence of items each of which begins with an explicit (2-byte) type, so you can include or omit, and reorder, extension items within the extensions field -- at least for encoding; whether a peer will accept a set of extensions is up to that peer.
If you want to implement TLS you really need to understand the applicable RFC(s) for the version(s) you want 2246/4346/5246, plus several related ones like 3546/4366/6066 for extensions, maybe 4492 (and SEC1 etc) for ECC, maybe added suites like 5288/5289 for GCM, etc.