کارگروه QUIC که برای استاندارسازی پروتکل در IETF پایه گذاری شد سریعاً تصمیم گرفت که پروتکل QUIC باید قادر باشد تا پروتکل‌هایی به غیر از "فقط" HTTP را هم انتقال دهد. پروتکل Google-QUIC تنها HTTP را انتقال داده است - در عمل آنچه را که بطور موثر قاب‌های HTTP/2 بوده است انتقال داده است، با استفاده از دستور و قواعد قاب HTTP/2.
همچنین اعلام شد که IETF-QUIC باید رمزگذاری و امنیت خود را به جای نگرش "دستی-سفارشی" بکار گرفته شده توسط Google-QUIC روی TLS 1.3 بنا کند.
به منظور برآوردن تقاضای بیش-از-HTTP-بفرست، معماری پروتکلِ QUIC کارگروه مهندسی اینترنت در دو لایه‌ی جدا تقسیم شد: انتقال QUIC و لایه‌ی "HTTP روی QUIC" (که دومی گاهی با عنوان "hq" یاد می‌شود).
این جدایی لایه‌ها، در حالی که ممکن است بی‌ضرر به نظر رسد، باعث شده است که IETF-QUIC تفاوت بسیاری نسبت به Google-QUIC اصلی پیدا کند.
با این حال طولی نکشید که کارگروه تصمیم گرفت تا به منظور پیدا کردن تمرکز و توان مناسب برای تحویل به موقع QUIC نسخه ۱، تمرکزش را بر روی تحویل HTTP قرار دهد و انتقال‌های غیر HTTP را برای بعد بگذارد.
در مارس ۲۰۱۸، هنگامی که ما کار بر روی این کتاب را شروع کردیم، برنامه آن بود که جزئیات نهایی برای QUIC نسخه ۱ را در نوامبر ۲۰۱۸ تحویل دهیم؛ بعدتر به تاریخ جولای ۲۰۱۹ موکول شد.
در حالیکه کار بر روی IETF-QUIC پیش می‌رفت، تیم گوگل جزئیاتی از نسخه‌ی IETF را استفاده کرده و به آرامی در جهت آنچه نسخه‌ی IETF ممکن است تبدیل شود شروع به توسعه دادن نسخه پروتکل خود کرد. گوگل به استفاده از نسخه‌ی QUIC خود در مرورگر و سرویس‌های خود ادامه داده است.
اکثر پیاده‌سازی‌های تحت توسعه تصمیم گرفته‌اند تا تمرکزشان را روی نسخه‌ی IETF قرار دهند و با نسخه گوگل سازگار نیستند.