本 EEP 描述了 gen_tcp 使用的新基本封包選項，這些選項也存在於 erlang:decode_packet 中，並且相同。
目前 erlang:decode_packet 中使用的封包選項涵蓋了一系列的封包類型。基本類型有 {packet,0}、{packet,1}、{packet,2} 和 {packet,4}。在 gen_tcp 的輸出流量中，這些選項會在封包前面加上 N 個額外位元組，其中包含一個大端格式的整數，表示資料的大小。
當與其他方實作的端點進行通訊時，並不總是能夠建議封包長度以大端格式表示，或是 4 個位元組。如今，隨著 64 位元機器的出現，我們甚至可能很快就會發現協議會以純粹的機器相依 64 位元字作為封包長度描述符發送。
本 EEP 建議將封包位元組擴展到 0-8 的範圍。請注意，內部最大封包大小不受此 EEP 影響，僅影響封包大小指示器的格式。
此外，建議使用負值範圍來表示 -1 .. -8 範圍內的小端格式大小指示器。{packet,-1} 等同於 {packet,1}。因此，前綴的封包位元組數量為 abs(PBytes)，其中 PBytes 的範圍為 -8 .. 8。
本 EEP 也建議使用固定大小的封包模式，表示為 {packet, {size,N}}。此模式在封包位元組方面與 {packet,0} 非常相似，不使用封包位元組。不同之處在於，在 {active,true} 或 {active,once} 模式下，當 {packet,0} 收集所有可用資料時，{packet,{size,N}} 模式會精確收集 N 個位元組，然後將其傳遞給「擁有者」程序。建議的實作最小值限制 N 為無符號 16 位元，因此最小值為 1，最大值為 65535。小於 1 的封包大小應始終導致 badarg 錯誤。
本 EEP 建議的封包類型為
{packet,P}
對於範圍為 -8 .. 8 的整數 P。這是對現有整數封包類型的擴展。
{packet,{size,N}}
N 的範圍 > 0，且最大 N 值取決於實作，但永遠不小於 65535。
本 EEP 的作者已在 Erlang/OTP 標準 git 發行版中實作了此提案，並且沒有發現任何向後相容性問題。受此提案實作影響的檔案為：inet_drv.c、packet_parser.c、packet_parser.h 和 erl_bif_port.c。
本文檔已置於公共領域。