Re: [sipcore] [Technical Errata Reported] RFC3261 (5619)
Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 01 February 2019 00:55 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 04EDB131196 for <sipcore@ietfa.amsl.com>; Thu, 31 Jan 2019 16:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 x321Haij13Ip for <sipcore@ietfa.amsl.com>; Thu, 31 Jan 2019 16:55:11 -0800 (PST)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69785131195 for <sipcore@ietf.org>; Thu, 31 Jan 2019 16:55:10 -0800 (PST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x110t7EO019394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <sipcore@ietf.org>; Thu, 31 Jan 2019 19:55:08 -0500
To: sipcore@ietf.org
References: <20190131181522.008FCB82E2D@rfc-editor.org> <DE825893-0C6C-4111-9A79-E9584CF136EA@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <0acbaf9b-4022-028e-c645-28cd49d818b3@alum.mit.edu>
Date: Thu, 31 Jan 2019 19:55:07 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <DE825893-0C6C-4111-9A79-E9584CF136EA@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/NXLKuz9zqakd37TyFDEK76tW3ks>
Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (5619)
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: Fri, 01 Feb 2019 00:55:14 -0000
On 1/31/19 2:12 PM, Ben Campbell wrote: > Hi, > > I think the point of the example was that Alice’s phone could have learned its home proxy via configuration or DHCP. Whether it learns an address, or a name that it then resolves with DNS is not material to the example. Perhaps it would have been more clear if some other word had been chosen than “address”. > > I lean towards rejecting this as a technical erratum. If people want to address the use of “address” as an editorial erratum, we could address that with a new errata report (which would likely be marked as “hold for update”. > > What do other people think? I think just reject it. > Thanks! > > Ben. > > >> On Jan 31, 2019, at 12:15 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote: >> >> The following errata report has been submitted for RFC3261, >> "SIP: Session Initiation Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5619 >> >> -------------------------------------- >> Type: Technical >> Reported by: Isabella Damböck <bella@rabenkind.at> >> >> Section: 4 >> >> Original Text >> ------------- >> The address >> of the atlanta.com SIP server could have been configured in Alice's >> softphone, or it could have been discovered by DHCP, for example. >> >> Corrected Text >> -------------- >> The address >> of the atlanta.com SIP server could have been configured in Alice's >> softphone, or it could have been discovered by DNS, for example. >> >> Notes >> ----- >> DHCP Server gives away the DNS-Server to use (or sets it with DHCP option) but usually does no address translation itself. It would also be possible to omit the whole sentence. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3261 (draft-ietf-sip-rfc2543bis-09) >> -------------------------------------- >> Title : SIP: Session Initiation Protocol >> Publication Date : June 2002 >> Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >
- Re: [sipcore] [Technical Errata Reported] RFC3261… Ben Campbell
- Re: [sipcore] [Technical Errata Reported] RFC3261… Paul Kyzivat
- Re: [sipcore] [Technical Errata Reported] RFC3261… Dale R. Worley