Re: [quicwg/base-drafts] [feature] Push messaging from server to client (#2664)

MikkelFJ <> Wed, 01 May 2019 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4FE21200C3 for <>; Wed, 1 May 2019 08:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yoHmR8MjrrTX for <>; Wed, 1 May 2019 08:47:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5C49120025 for <>; Wed, 1 May 2019 08:47:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=lXuQd/h8JLW0vaYI14uw6VWHjXM=; b=e4jySrz7CBvcQNUb 6yDNAUoCR7R/IzCHlD1TnSFVYnjR3QV8tupCSRpYmXt25bFnmoQZvXFNwzPCFOE0 BJxAFLSMe0gaRm0sg7UnlA/Mz+3fdqgH1c8oEujt52nOIX90EtdPEZEK+0aTA95O XQMk++5FhXfDXxRGeoOefvP7Pmo=
Received: by with SMTP id filter1046p1las1-9385-5CC9BFAC-D 2019-05-01 15:47:56.317412815 +0000 UTC m=+498557.427666222
Received: from (unknown []) by (SG) with ESMTP id d2vgfwFIS76Ayly9coi_rw for <>; Wed, 01 May 2019 15:47:56.178 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 0E344361F3E for <>; Wed, 1 May 2019 08:47:56 -0700 (PDT)
Date: Wed, 01 May 2019 15:47:56 +0000 (UTC)
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2664/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] [feature] Push messaging from server to client (#2664)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc9bfacc875_605d3f8ac22cd9681085dd"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1UwGZlfCDUu33fAeuemHNfg8s2+KCzZ3hPmy 1whqRvF46ktg28lhK/KWuG0Gw/ur1zNsungQLMRfyoGuYUvkhPOb09IC6q5WspKFdwm6xU2YC8vbmw n1I0aMKiGnHLOcFmISsGjb4OoA8oMTgZvb8sCyPi6MYIKnklWXRwe2jLfjzGtTkVo4i+A012iyvUdS g=
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 May 2019 15:48:01 -0000

Why don’t you use MQTT for this?
Work is needed on standardising MQTT for QUIC though.

The intervals could be handled through a separate control topic.


On 1 May 2019 at 17.22.57, Patrick ( wrote:

Hi all,

based on the work we did on I
want to request adding new functionality which can be implemented with two
new VERBS and two new headers.

*Use Case:*
Clients want to subscribe to urls, as topics with all the filtering, paging
information etc. being expressed in the url. This would allow services to
push information into clients whenever it is considered necessary.

As subscriptions are a "convenience" method compared to polling via GET, I
propose two new HTTP Verbs

   - SUB for subscription to url
   - UNSUB for un-subscribing from url

To control the frequency of updates, we would need additional headers:

   - subscription-interval:
   - subscription-updatelimit:

The optional interval attribute specifies the update frequency in
milliseconds for periodic updates, while the optional updatelimit attribute
specifies the maximum update rate in milliseconds for ‘on change’
notification. If interval is set, updatelimit is always overruled.

*On change*
If interval is not set, the notification interval is defined ‘on change’
and can be limited by specifying an updatelimit. If an ‘on change’ occours
before updatelimit elapsed, an event will be sent as soon as updatelimit
elapsed. If there are multiple changes before the next possible update,
only the last one know state is sent after updatelimit elapsed.

As this is very close to a regular GET, it would be easy and we could also
standardise that per each client-server relation, there would just be a
single UDP/IP channel for notifications used and held up. We could also
specify that this is a "simplex" connection regarding payload data. as
clients would use other HTTP verbs to send data. Each data sent from the
server to the client would be exactly the same as a GET response. Very
straight forward from my perspective and a valuable extension of the
standard for all things "realtime".

All the Headers we replicate in WebSockets today.. puuuffff gone ;) we can
just plain HTTP headers...

The viwi/RSI spec would than be just rewrote to hold the interface design
rules etc. the entire WebSocket parts would be obsolete.

Also It would than not be relevant anymore wether we transmit JSON (text)
or binary content..

Think of it as a GET with multiple responses.. same formats, payloads,
everything.. just not req/res but req/res/res/res/res... including all
status codes etc.

Re-Auth would also just be another SUB request with a new Token.. super
easy ;)

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<>, or mute the thread

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: