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

Patrick <notifications@github.com> Wed, 01 May 2019 15:23 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1D2431200F8 for <quic-issues@ietfa.amsl.com>; Wed, 1 May 2019 08:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LOl2N8dCln_a for <quic-issues@ietfa.amsl.com>; Wed, 1 May 2019 08:23:04 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCDB120025 for <quic-issues@ietf.org>; Wed, 1 May 2019 08:23:04 -0700 (PDT)
Date: Wed, 01 May 2019 08:23:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556724183; bh=XyHTFRk5fyQbrF1+ohafUKkJXrT2Ya90/hLBpwhEjuI=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=eqdRBvfWi56haIZLzNfWPLVt6orPLvEIPP7RXOnTWgIiZda4GijTM3vKzOan/Xo/f mMWG17FiP3SgPUvLBXSfh2POzj29avA8W+nhsA7g9XnyOIcVKNupoQ3o0zsYY4eod7 i6qEoWv92IEVfVhuj+hoddHnVeItimov8uAreyd4=
From: Patrick <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4SHBRGE5TPIZ2FO7F223WFPEVBNHHBULNVFE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2664@github.com>
Subject: [quicwg/base-drafts] [feature] Push messaging from server to client (#2664)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc9b9d712d29_77983fcf6accd96c1288e8"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: wzr1337
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/gBQJu0BmdHOoQ4hi5kf0EK3k9Z8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 May 2019 15:23:06 -0000

Hi all,

based on the work we did on https://www.w3.org/Submission/viwi-protocol/ 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: <timeStepInMs> 
* subscription-updatelimit: <timeStepInMs>

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 or view it on GitHub: