IETF Logo Mail Archive

Re: deprecating Postel's principle- considered harmful

"Salz, Rich" <rsalz@akamai.com> Tue, 07 May 2019 21:09 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328D012014A; Tue, 7 May 2019 14:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ZK4JOaCmScLU; Tue, 7 May 2019 14:09:03 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9AD2D120086; Tue, 7 May 2019 14:09:03 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x47L724M010070; Tue, 7 May 2019 22:08:59 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=7Ot/0mQBsv+zvajM1zXeZS/ZO+4kAygKCTxtFuHhlEA=; b=TxfSm4/qKK/YUFzGb3D+2Cor284rROVz0Vu0hopGquxalafdEAgFYgXvJfA7ohH52T3N dCKNKIro9AdfN5BkpyoKvT4hcOWD2YFHAB0dQ0mcXb9D0fo+hgTQTr3yimzoR26w84Lc UEw3qQ0qmuRK+KTT+wApD1QBies9nXCtiuQNbcQcadW8ilkDknqnqLmbMyNS/+zTTvO2 6EeRnp8rKrxYBQr8Fi9fru9r57ju3Qk8RfArdWEHJlKiIOqVkcRvWJKRnVl9y/29P3Dm XjeNnS+DowQ/NqXxfOClw4KvcAmvdVuIi/WQde1JVMQi0cvsIidFvcjJ5bjazscgrEOY 8A==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2sbeju0fv5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 May 2019 22:08:59 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x47L2ImV010513; Tue, 7 May 2019 17:08:59 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2s962xwmg4-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 May 2019 17:08:47 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 May 2019 16:08:40 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Tue, 7 May 2019 16:08:40 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Adam Roach <adam@nostrum.com>, "Andrew G. Malis" <agmalis@gmail.com>, Barry Leiba <barryleiba@computer.org>
CC: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "iab@iab.org" <iab@iab.org>, "ietf@ietf.org" <ietf@ietf.org>, "BRUNGARD, DEBORAH A" <db3546@att.com>, The IESG <iesg@ietf.org>
Subject: Re: deprecating Postel's principle- considered harmful
Thread-Topic: deprecating Postel's principle- considered harmful
Thread-Index: AdUFA25WR9rFDya0SW+KpydJfyj0sAAOhC0AAACnfQAAAGmngP//v1GA
Date: Tue, 07 May 2019 21:08:39 +0000
Message-ID: <0E0AD36F-8857-4591-AB43-E29F6FD82850@akamai.com>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <CAA=duU1TxZx9W8huPp5md25Wf+9=f50WYGpU=Bb1OQ+OdF6k6A@mail.gmail.com> <6569841c-4de7-01c4-0326-9419b453988c@nostrum.com>
In-Reply-To: <6569841c-4de7-01c4-0326-9419b453988c@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.19.0.190502
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.214]
Content-Type: text/plain; charset="utf-8"
Content-ID: <60700826594FA24B8792F4E8EEF3F712@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-07_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=667 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905070131
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-07_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=673 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905070132
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NWUtpJUj6Yy1ih6Rgj8FJGtwW-0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2019 21:09:05 -0000

> I read this as 
    suggesting that maybe future protocols should be a bit more picky about 
    not accepting messages that are malformed or sequences of messages that 
    are unorthodox, even if some degree of processing is technically possible.
  
Then perhaps change the title to something that doesn't act like a red flag.

"On the benefits of XML-style strictness in protocols" perhaps?

v2.23.0 | Report a Bug | By Email