Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the COMMENT issues

Ben Campbell <ben@nostrum.com> Tue, 08 January 2019 21:29 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D751813117E for <sipcore@ietfa.amsl.com>; Tue, 8 Jan 2019 13:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbZIYocepYMg for <sipcore@ietfa.amsl.com>; Tue, 8 Jan 2019 13:29:50 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF0513117D for <sipcore@ietf.org>; Tue, 8 Jan 2019 13:29:50 -0800 (PST)
Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x08LTlEl040931 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Jan 2019 15:29:48 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546982989; bh=dLcp+zKPXXyijn4Zg/LIPnHrM5IrPdvXUQ9TTctk8VI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=FzZ4XUSGx5CbyOrWQ9o0tXGxJM61BNDG86wlx9StMBJ+IyJQ+lMBlnAg1WR36aKEG ihehRavayJH/Ws8TCU2Mx/Ing0jt2IpMv2fOFjQUv6fisfBWfL5fzELGnZWVOw00LI CEeUwkvV1NskBx+33RDi8iJmrLHY6lkUAuKfKyhE=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <14B775F3-3115-47BE-AC68-BC45FCD78702@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_BD9EE025-5AD0-454B-8884-96C5C13F4BE3"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 08 Jan 2019 15:29:46 -0600
In-Reply-To: <HE1PR07MB31618B1CE0907B10CB8E1C5393890@HE1PR07MB3161.eurprd07.prod.outlook.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "sipcore-chairs@ietf.org" <sipcore-chairs@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>, "draft-ietf-sipcore-sip-push@ietf.org" <draft-ietf-sipcore-sip-push@ietf.org>, The IESG <iesg@ietf.org>, "br@brianrosen.net" <br@brianrosen.net>
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <154681733718.17024.3190954246737206843.idtracker@ietfa.amsl.com> <HE1PR07MB31611EECBA89EF1FC46D756C93890@HE1PR07MB3161.eurprd07.prod.outlook.com> <CABcZeBPQTxcMxSmAdtd6JdGyfq8zGWuK9ZZO22SwdKX7RzSJdA@mail.gmail.com> <HE1PR07MB31618B1CE0907B10CB8E1C5393890@HE1PR07MB3161.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/ajws6KiIdg6aEYMMZlbxA6B0Q7c>
Subject: Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the COMMENT issues
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 21:29:52 -0000


> On Jan 7, 2019, at 1:04 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> 
> Hi,
> 
> S 1.
> >>      will request push notifications towards the UA.
> >>
> >>      When the proxy receives a SIP request for a new dialog or a stand-
> >>      alone SIP request addressed towards a UA, or when the proxy
> >>      determines that the UA needs to send a binding-refresh REGISTER
> >>      request, the proxy will request a push notification towards the UA,
> >
> > "request ... towards" is ungrammatical
> 
> Is "request a push notification to be sent towards the UA" better?
> 
> >I would say "request that a push notification be sent to"
> 
> Ok.
> 
> ...
> 
> S 4.1.
> >>
> >>      NOTE: The VAPID specific procedures of the SIP UA are outside the
> >>      scope of this document.
> >>
> >>      When the UA receives a push notification, it MUST send a binding-
> >>      refresh REGISTER request, using normal SIP procedures.  If there are
> >
> >This seems unnecessarily restrictive. Are we never going to want any
> >other kind of push notification?
> 
> Well, in order for this mechanism to work, it has to be a MUST, and the procedures obviously only applies to UAs that use the SIP push mechanism.
> 
> >Yeah, this seems like a pretty major architectural flaw in this design, tbh, one that is
> >remedied by just using RFC 8030-style notifications that contain content.
> 
> Other push notification services support content too, but we decided that we are not going to specify that for SIP push.
> 
> IF there comes a future case, where multiple SIP usages of push notifications have to co-exist, we can define usage of content (and e.g., define that SIP push is default).

Just a note: This came up in WG discussion and again during the AD evaluation. IIRC, the consensus was to not attempt to solve the issue in this draft.

That being said, I think it would be worth including a note that the potential exists and is being punted to the future.

Thanks,

Ben.