IETF Logo Mail Archive

Re: [sipcore] [Technical Errata Reported] RFC7118 (5937)

Roman Shpount <roman@telurix.com> Thu, 19 December 2019 20:27 UTC

Return-Path: <roman@telurix.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 94A1F120B6A for <sipcore@ietfa.amsl.com>; Thu, 19 Dec 2019 12:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 NAmakDJAl6Od for <sipcore@ietfa.amsl.com>; Thu, 19 Dec 2019 12:27:27 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 DBACD120A96 for <sipcore@ietf.org>; Thu, 19 Dec 2019 12:27:26 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id w1so8732340otg.3 for <sipcore@ietf.org>; Thu, 19 Dec 2019 12:27:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pChR1kQGol8jobQF3YpBKUjQ8WOaTlAWgGU0u+Wej7Q=; b=mEmn1M8vJ4g8I6L55OLhA/k8NONqjr5xfaIQ8kpW+0sBluW7oKea35za1RWuLFSLMK 3qZMAFi3EXAcUMQNxz590TW9JwbJoloBzFDnQEmCQQWoR3ciFszedmi0cO4KLxyozFG1 RczUtyh/BRobfyEyx8hL/O8KsWnulGIkPFVwDekG6rKmBhlGEppF8onuyaDQUibFKyl1 RVznrwzEmwMeTv6AAvN4M8uRfHxD4hsqeXYhoWcpF5+qosBiGB/aO6wYrTk+YnEBTMDS vOFP0knJVEpsO91fUlmRQ4bloLw1RbafvLS38i6N8ktbNrPNblxCtjAAuOtKlVf8gAXq +Org==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pChR1kQGol8jobQF3YpBKUjQ8WOaTlAWgGU0u+Wej7Q=; b=eg3UxgpaJGkXQkM+fzrpI0IfKhBIiouSH0lVOHZJ1WQkZ/DrsnpIauudpAn7oVYG+k Og+aHFlpNcrRMLz3sup/CD+9NXN40aQJViKEfDPR8DWEVu/tEqpKlgeJHqaTb4c8ZhvZ TVK+ilgM2KIpQMA4wlDK3ngQtcQpSg3T2D+dZLEAEHYtXgtJaDVZodvuBRz0Ck0zbv6E qR+/IRNp2PVeZpdNlYcgGESNnBryYjIGy5Jt/f7FUPSVYPyem8gTzvqXa7DG9dCr7C7y zFlR4b0c1QoBXmqzVUnIt/7fKcXAgdTMA8i7GBgT8D0hiq+JxohW5SZl3NNjEfAPY6x6 LVfw==
X-Gm-Message-State: APjAAAVRpjQWYTi84u5XG5q74PR4pfwkzUeifCNFHutI/4W0yEIocVyi 3jiE5bwYeuAObm/FoFXSt3cGuspuLlw=
X-Google-Smtp-Source: APXvYqz/2miLZB4RjNvTQSePANnuWuDNdaBQuKNR/1BMnuxHGDPVSAuA1eS8MZ4SuXew5iZFKTgE6Q==
X-Received: by 2002:a9d:748d:: with SMTP id t13mr10395666otk.181.1576787245587; Thu, 19 Dec 2019 12:27:25 -0800 (PST)
Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com. [209.85.167.177]) by smtp.gmail.com with ESMTPSA id q1sm2595211otr.40.2019.12.19.12.27.24 for <sipcore@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Dec 2019 12:27:24 -0800 (PST)
Received: by mail-oi1-f177.google.com with SMTP id i1so3647539oie.8 for <sipcore@ietf.org>; Thu, 19 Dec 2019 12:27:24 -0800 (PST)
X-Received: by 2002:aca:c5ca:: with SMTP id v193mr3171291oif.77.1576787244024; Thu, 19 Dec 2019 12:27:24 -0800 (PST)
MIME-Version: 1.0
References: <20191214200623.98A51F406CB@rfc-editor.org> <CALiegfk0DmcB0Kak+1Y6jDLqzY_0zVo0qweY1+0CCo-E3C-c6w@mail.gmail.com> <CAD5OKxsK+2VH-3a=RbSkOhHB=HPbVOs-CEHbho-CX0PWXuyqZA@mail.gmail.com> <CAD5OKxtZK+irOGk5r6Gj1QKSnEqw5bc7_sxN+VBZxoyURk=DOA@mail.gmail.com> <CALiegfk4M-U75XFSygL85Pqazuf642ig8iHiVqw5gNzfnD2jmw@mail.gmail.com> <CAD5OKxsUuGKp3GNW3SRjoLjkcFJp_yK_NCfL77e4_OUi3BoPuw@mail.gmail.com> <CALiegfn_BGApF36aZEeUxV6NKOfEFRZ8w-CyT_eKFQjRDzuPsQ@mail.gmail.com>
In-Reply-To: <CALiegfn_BGApF36aZEeUxV6NKOfEFRZ8w-CyT_eKFQjRDzuPsQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Thu, 19 Dec 2019 15:27:14 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtPaNO0FXrC71jn8wsOynCknuaeNQpXxXB1SXE5u=FkGw@mail.gmail.com>
Message-ID: <CAD5OKxtPaNO0FXrC71jn8wsOynCknuaeNQpXxXB1SXE5u=FkGw@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, José Luis Millán <jmillan@aliax.net>, Ben Campbell <ben@nostrum.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, Adam Roach - SIPCORE Chair <adam@nostrum.com>, Brian Rosen <br@brianrosen.net>, "A. Jean Mahoney" <mahoney@nostrum.com>, SIPCORE <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000910bd1059a14634e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/OQrFG1IQsVA7Spv898adXdcdPPw>
Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937)
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: Thu, 19 Dec 2019 20:27:28 -0000

On Thu, Dec 19, 2019 at 11:26 AM Iñaki Baz Castillo <ibc@aliax.net> wrote:

> On Thu, 19 Dec 2019 at 16:06, Roman Shpount <roman@telurix.com> wrote:
> >
> > On Sun, Dec 15, 2019 at 5:54 PM Iñaki Baz Castillo <ibc@aliax.net>
> wrote:
> >>
> >> Yeah, that's exactly the section I meant :)
> >>
> >> On Sat, 14 Dec 2019 at 21:42, Roman Shpount <roman@telurix.com> wrote:
> >> >
> >> > It looks like RFC 5630 allows this and there is a description of such
> flow in  https://tools.ietf.org/html/rfc5630#section-6.4.
> >>
> >
> > One small nit that in the RFC7118 example, according to
> https://tools.ietf.org/html/rfc5630#section-6.4, there should not be
> "transport=ws" or any other transport in the URI in the Route header. Since
> this Route URI is simply there for the proxy to identify that the message
> was correctly routed and remove, this is just a nit.
>
> I don't think there is a MUST NOT for that, nor that such a
> transport=ws is really invalid, is it?
>

It is not invalid, it just adds to overall confusion. This transport
parameter (and likely the whole route header) is irrelevant. This is why it
is a nit.
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email