From nobody Wed Aug 3 15:05:49 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F612D093 for ; Wed, 3 Aug 2016 15:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Wql4zOny0fP2 for ; Wed, 3 Aug 2016 15:05:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B19012B02D for ; Wed, 3 Aug 2016 15:05:47 -0700 (PDT) Received: (qmail 97950 invoked from network); 3 Aug 2016 22:05:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Aug 2016 22:05:47 -0000 Date: 3 Aug 2016 22:05:24 -0000 Message-ID: <20160803220524.59905.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <40c227db-76ff-15bd-3358-ba85a63f1b59@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 22:05:49 -0000 > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ >We think the Apps area will have a vested interest in not only the >registry, but ensuring all current applications are documented. We >welcome any and all feedback I still think this is long overdue. Is anyone else interested? R's, John From nobody Wed Aug 3 15:20:29 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2920012D8A3 for ; Wed, 3 Aug 2016 15:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no 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 F7QVhLxg2zRz for ; Wed, 3 Aug 2016 15:20:27 -0700 (PDT) Received: from simon.songbird.com (unknown [72.52.113.5]) (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 C723212D674 for ; Wed, 3 Aug 2016 15:20:26 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u73ML5Er030241 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 3 Aug 2016 15:21:06 -0700 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Tim Wicinski References: <40c227db-76ff-15bd-3358-ba85a63f1b59@gmail.com> <08FD5E91-BB1B-4190-AD00-5BE6505556D6@frobbit.se> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 3 Aug 2016 15:20:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <08FD5E91-BB1B-4190-AD00-5BE6505556D6@frobbit.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 22:20:28 -0000 On 7/20/2016 1:59 AM, Patrik Fältström wrote: > On 20 Jul 2016, at 7:57, Tim Wicinski wrote: > >> This draft is not just looking at SRV records, but TXT records which document such behavior. > > And URI. URI: I think I didn't respond to this: URI showed up after the original drafting of the doc, but yes it needs to be included. However after some very basic research it appears that the URI RR does not yet have traction. So the current doc needs to account for its existence but I think it does not create additional registry entries, especially since it emulates SRV. Subordindate Table(s): More significant is the handling of the second-level underscore node name for the two-level naming constructs (where the upper-level is a protocol string, used by SRV and URI. Ray had suggested a way to deal with this quite a long time ago and I promptly forgot what it was. When the topic renewed during Berlin, I finally gravitated towards a model that luckily was along the lines he proposed... In practical terms, the second-level underscore names need to be registered explicitly, although one might think the SRV doc has covered this by pointing to a table. By my reading, that reference is more conceptual than a detailed registry reference. The set of protocol (upper-level) names is small and should be in the registry explicitly. One might argue that the reference to the separate protocol table suffices but this is a case that seems better handled by the mild redundancy. As for the second-level underscore names, I propose that they /also/ be registered in this one table. In theoretical terms, one could argue for a separate table, or maybe many of them (one under each top-level underscore protocol name) but that purity-drive choice seems somewhere between inefficient and silly. If we thought there would be lots of independent uses of the same name, but under different upper-level underscore (protocol) names, we'd need all the separate, subordinate names. And indeed, this is what bogged me down originally. But no one, including me, so far thinks this is a realistic need. So finding a way to simplify this down to one table seems eminently reasonable. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 3 19:00:14 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4738B12B05D for ; Wed, 3 Aug 2016 19:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 pG_F-2f1j2L4 for ; Wed, 3 Aug 2016 19:00:11 -0700 (PDT) Received: from miucha.iecc.com (miucha.iecc.com [64.57.183.18]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F3E12B00F for ; Wed, 3 Aug 2016 19:00:11 -0700 (PDT) Received: (qmail 56436 invoked from network); 4 Aug 2016 01:59:03 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Aug 2016 01:59:03 -0000 Date: 4 Aug 2016 01:58:40 -0000 Message-ID: <20160804015840.60405.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 02:00:13 -0000 >As for the second-level underscore names, I propose that they /also/ be >registered in this one table. In theoretical terms, one could argue for >a separate table, or maybe many of them (one under each top-level >underscore protocol name) but that purity-drive choice seems somewhere >between inefficient and silly. That doesn't seem like a great idea. According to RFC 2782, SRV names are: _service._protocol.blah.example Name assignment was a mess due to the rather casual advice in 2782 until RFC 6335 cleaned it up five years ago. There appear to be only four protocols that have ever been used for SRV records: _udp, _tcp, _sctp, and _dccp. RFC 6335 refers to them but doesn't set up a registry. The names are in the Assigned Internet Protocol Numbers registry, but most of the entries in that registry are obsolete and some have names with plus signs and other unfortunate characters, so I think it'd be fine to put the live protocol tags into your list. The services, on the other hand, were thoroughly cleaned up by RFC 6335. It collected a bunch of informal lists into one place, renamed a few old names with unfortunate characters, and put them into a tidy and very large Service Name and Transport Protocol Port Number Registry. It says in section 5.2 that the service name for a SRV record MUST follow the syntax rules (ldh with at least one letter and no leading or trailing or double hyphens, prefixed with an underscore) and SHOULD be registered in the registry. That registry is FCFS for service names and now contains over 10,000 entries, so if you are aware of any SRV service names not listed, it'd make a lot more sense to register them than to try to define something new that sort of mirrors one of the largest registries that IANA manages. For URI records RFC 7553 says they're either named the same as SRV records, or they use enumservice names from the Enumservice Registrations registry which lists two dozen types, most of which have specific allowed subtypes. This registry is a lot smaller than the service name registry, but it exists, the RFC points to it, and it seems unwise to copy its contents somewhere else. Other than SRV and URI records, there's a handful of two component prefix names like _adsp._domainkey and _report._dmarc. As far as I tell the rest are all all one or two per main name, so listing them shouldn't be too hard. But please, don't duplicate registries that already exist. R's, John From nobody Wed Aug 3 19:58:15 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C5E12D841 for ; Wed, 3 Aug 2016 19:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 X22FXEHDe2eT for ; Wed, 3 Aug 2016 19:58:11 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 61C1312D14F for ; Wed, 3 Aug 2016 19:58:11 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id x196so1621317ybe.1 for ; Wed, 03 Aug 2016 19:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=GNnwzPWXq1Vu9sp06FC2R6ExGnFSTwyyO1Sh6xqxu24=; b=YfEEAt1cUTghrcijKC5p07xHL9ICp7BR7heBbuIfxVscavYCw0TjcIxdFDo5DY8eC3 Mqk5pqvFrwV0n9MHZU55Y12jeAfE9Q9RP29XuorJmrXE5P6A5Gs1O4AVz7lmUT+vNX4z QF6eWOSZMWp8p8MLtw+FRuPAcBkoIAf1aBpfpHGVURb0bSdIVbPN/Zg+UJN388bgAAG5 liRnpx0lOCpBn3KXfc3pNxFTyu+pC4Y3TCJwzsNxcSqxLfrUGgcwyR5VKLQOJ8BJKUZj uveRJ9Nl1fkFEw9wjp3L/b3yRSb9mH2tWTR37gWjwZ4BM4VMhEAalIQt3uTCny82MO8m hJRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GNnwzPWXq1Vu9sp06FC2R6ExGnFSTwyyO1Sh6xqxu24=; b=W4YtFWKf3zQQGC2HYYBU8S7y3ohmq72LbgGX5XbZVLnVnhil2ktuppFm2lwgikxvHj wnibX9zP7UR+H8cEK4h+J/rBzcIpuqkMyaGeFUvRp/JM8ca6CDC4Z78iKuaVXsXM2gP8 Wn1gmzFlAyRPI7yBHnZF2Uqd4bw29MZVH5Cg8NhArPZOQ1LcWUOs96GgZ04g2QaGW3bb abzZLQ95imZyZkVbfJsF276qOITZqPTbziexyCp+EL6gqdM0i5Tg9tSzYGxc4fTPQkkp dQiQlDwrUNNMOYirdtIcFx7jlV2SbMuLf1uuAKYmfod5aYjTAvo3XgF+30s9zdxOgN1O VeKA== X-Gm-Message-State: AEkoouuoLzb+Ic/OlSMTM0mCHGXXegZ1WJZedXjUJKaeXjTqpnkWK4kp3b+yG09vum7BmQgo4URjAUYQgkOOCg== X-Received: by 10.37.64.6 with SMTP id n6mr20529222yba.32.1470279490304; Wed, 03 Aug 2016 19:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.84 with HTTP; Wed, 3 Aug 2016 19:58:09 -0700 (PDT) From: "Murray S. Kucherawy" Date: Wed, 3 Aug 2016 19:58:09 -0700 Message-ID: To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c00866bd80e90539361e3c Archived-At: Subject: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 02:58:13 -0000 --001a11c00866bd80e90539361e3c Content-Type: text/plain; charset=UTF-8 Colleagues, The authors, ADs, and I have discussed this newest version and feel there have not been enough material changes to the draft since Working Group Last Call completed to warrant a second WGLC. Accordingly, this will progress shortly toward IETF Last Call and IESG evaluation. A diff to the version that was WGLC'd: https://www.ietf.org/rfcdiff?url1=draft-ietf-appsawg-mdn-3798bis-02&url2=draft-ietf-appsawg-mdn-3798bis-10 If you have any final comments please provide them to the list, the chair, or the authors ASAP. -MSK ---------- Forwarded message ---------- From: Date: Sun, Jul 31, 2016 at 10:23 AM Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt To: i-d-announce@ietf.org Cc: apps-discuss@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-09.txt Pages : 35 Date : 2016-07-31 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c00866bd80e90539361e3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The authors, ADs, = and I have discussed this newest version and feel there have not been enoug= h material changes to the draft since Working Group Last Call completed to = warrant a second WGLC.=C2=A0 Accordingly, this will progress shortly toward= IETF Last Call and IESG evaluation.=C2=A0 A diff to the version that was W= GLC'd:

https= ://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-appsawg-mdn-3798bis-02&url2= =3Ddraft-ietf-appsawg-mdn-3798bis-10

If you have any final= comments please provide them to the list, the chair, or the authors ASAP.<= br>
-MSK


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Jul 31, 2016 at 10:2= 3 AM
Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt
To: <= a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org
Cc: apps-discuss@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the ART Area General Applications Working Grou= p of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Disposition Notification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tony= Hansen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alexey Melnikov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-mdn-3798bis-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 35
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-07-31

Abstract:
=C2=A0 =C2=A0This memo defines a MIME content-type that may be used by a ma= il user
=C2=A0 =C2=A0agent (MUA) or electronic mail gateway to report the dispositi= on of a
=C2=A0 =C2=A0message after it has been successfully delivered to a recipien= t.
=C2=A0 =C2=A0This content-type is intended to be machine-processable.=C2=A0= Additional
=C2=A0 =C2=A0message header fields are also defined to permit Message Dispo= sition
=C2=A0 =C2=A0Notifications (MDNs) to be requested by the sender of a messag= e.=C2=A0 The
=C2=A0 =C2=A0purpose is to extend Internet Mail to support functionality of= ten
=C2=A0 =C2=A0found in other messaging systems, such as X.400 and the propri= etary
=C2=A0 =C2=A0"LAN-based" systems, and often referred to as "= read receipts,"
=C2=A0 =C2=A0"acknowledgements", or "receipt notifications.&= quot;=C2=A0 The intention is to
=C2=A0 =C2=A0do this while respecting privacy concerns, which have often be= en
=C2=A0 =C2=A0expressed when such functions have been discussed in the past.=

=C2=A0 =C2=A0Because many messages are sent between the Internet and other<= br> =C2=A0 =C2=A0messaging systems (such as X.400 or the proprietary "LAN-= based"
=C2=A0 =C2=A0systems), the MDN protocol is designed to be useful in a multi= -
=C2=A0 =C2=A0protocol messaging environment.=C2=A0 To this end, the protoco= l described
=C2=A0 =C2=A0in this memo provides for the carriage of "foreign" = addresses, in
=C2=A0 =C2=A0addition to those normally used in Internet Mail.=C2=A0 Additi= onal
=C2=A0 =C2=A0attributes may also be defined to support "tunneling"= ; of foreign
=C2=A0 =C2=A0notifications through Internet Mail.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-appsawg-mdn-3798bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-= appsawg-mdn-3798bis-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-appsawg-mdn-3798bis-09


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/list= info/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c00866bd80e90539361e3c-- From nobody Wed Aug 3 20:50:21 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BAB12D1B2 for ; Wed, 3 Aug 2016 20:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no 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 y5huFIss3MQH for ; Wed, 3 Aug 2016 20:50:20 -0700 (PDT) Received: from simon.songbird.com (unknown [72.52.113.5]) (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 0AF4112D16F for ; Wed, 3 Aug 2016 20:50:20 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u743p71e011395 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 3 Aug 2016 20:51:07 -0700 To: John Levine , apps-discuss@ietf.org References: <20160804015840.60405.qmail@ary.lan> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <62b38d70-3b02-63a7-e722-099e9fcf3c18@dcrocker.net> Date: Wed, 3 Aug 2016 20:50:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160804015840.60405.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 03:50:21 -0000 On 8/3/2016 6:58 PM, John Levine wrote: > That doesn't seem like a great idea. According to RFC 2782, SRV names > are: Sorry folks. I initiated a discussion about the draft on this apps-discuss list, when it is supposed to take place on dnsop. I've forward my mis-posted original 'proposal' note to dnsop, along with John's response and my response to John... So, please do /not/ respond on this thread, on apps-discuss. Take it to dnsop. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Aug 4 02:22:19 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B120E12D88C for ; Thu, 4 Aug 2016 02:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 qouuogprGyAa for ; Thu, 4 Aug 2016 02:22:15 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 8A82812D89C for ; Thu, 4 Aug 2016 02:22:12 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from grey.csi.cam.ac.uk ([131.111.57.57]:57219) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1bVEqt-000XC0-ML (Exim 4.87) (return-path ); Thu, 04 Aug 2016 10:22:07 +0100 Date: Thu, 4 Aug 2016 10:22:07 +0100 From: Tony Finch To: John Levine In-Reply-To: <20160804015840.60405.qmail@ary.lan> Message-ID: References: <20160804015840.60405.qmail@ary.lan> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 09:22:18 -0000 John Levine wrote: > > There appear to be only four protocols that have ever been used for > SRV records: _udp, _tcp, _sctp, and _dccp. _tls is commonly used in SIP deployments. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Wight, Portland, Plymouth: West 4 or 5, increasing 6 at times. Rough at first in Plymouth, otherwise moderate. Showers. Good. From nobody Thu Aug 4 06:36:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA3312B071 for ; Thu, 4 Aug 2016 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=97HRY8en; dkim=pass (1536-bit key) header.d=taugh.com header.b=nx9mT81q 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 SqPnJNErJfA8 for ; Thu, 4 Aug 2016 06:36:03 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4102112B063 for ; Thu, 4 Aug 2016 06:36:03 -0700 (PDT) Received: (qmail 22475 invoked from network); 4 Aug 2016 13:36:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=57ca.57a344c3.k1608; bh=0eCDe9tPNesmJ7fIPFaeE9+tfL+D1Ie6OmsFeWQ+wZM=; b=97HRY8enFCHXpv6nnQrfdVYvWWpj42rWUejVjvFMW8/+gmnvRuBPDfmy+fs5zswuHkTOrXyftQj7QWfGPUu4xpEfxFqITat+uG/393uYXN3zXsM+THWtHfzYoS9un+uCqUcQsq/j/tG7MiemoTi3KjxaRzaMVITE6P0kwwSg/dzZfOkprN/qIiEr+yH09aWh4kjf9JLj2lQBUn+5NxHvHSFqewkAcsYbsJ44Vj5qFfPK6L9cldPr1k3tOpwWMaFV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=57ca.57a344c3.k1608; bh=0eCDe9tPNesmJ7fIPFaeE9+tfL+D1Ie6OmsFeWQ+wZM=; b=nx9mT81q2YzvcQXNmFSk7WJp5ojPaYuHtJLtp93klTIdQ0B/mlj11Zr8VhOHQfVtlIObTgWhXZdEckI5+SRFV4GZ2n2f6CwO5RFBlT7LJVTwyZemfcXSnsoySydmF64q7kx2sBkdaEj0UFp/x0UZviX+kGwQw6dqiBeNYXm9GKUe36jsRg68KBwBPVM+x0jrg/LuCY2S7AY3rieQ4sbHPd3Qqg08ZmIibD2PZLanCtZYdg9ROj9ktLKhro4LEgvW Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 04 Aug 2016 13:36:03 -0000 Date: 4 Aug 2016 09:36:01 -0400 Message-ID: From: "John R Levine" To: "Tony Finch" In-Reply-To: References: <20160804015840.60405.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:36:05 -0000 >> There appear to be only four protocols that have ever been used for >> SRV records: _udp, _tcp, _sctp, and _dccp. > > _tls is commonly used in SIP deployments. Huh. The only place I see _tls in an RFC is as an example in the DIAMETER spec in RFC 6733. I believe you, but once again we have the question about what to do with stuff seen in the wild that's not actually defined anywhere. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Aug 4 07:14:23 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AA712D98E for ; Thu, 4 Aug 2016 07:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 59m9U1h7Dqw6 for ; Thu, 4 Aug 2016 07:14:18 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C67F12D544 for ; Thu, 4 Aug 2016 07:14:17 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bVJPb-000AEl-MF; Thu, 04 Aug 2016 10:14:15 -0400 Date: Thu, 04 Aug 2016 10:14:10 -0400 From: John C Klensin To: "Murray S. Kucherawy" , IETF Apps Discuss Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 14:14:22 -0000 Murray, Tony, and Alexey, I don't know how to think about this draft in context, but my problem is not with the specific changes to 3798. We've got Proposed Standards for internationalized headers and addresses from the EAI WG (RFC 6530ff) that include an i18n MDN specification (RFC 6533). One of the arguments against doing or standardizing that work at all was that it basically created a fork in the email environment with mutually-incompatible ASCII-only (including encoded words, etc.) and i18n-native environments. When the WG and IETF adopted the SMPTUTF8 ("EAI") specifications as Proposed Standards, most of those who were actively involved knew that the only basis on which the situation they created would be viable long-term was if it was transitional to fully-internationalized mail and that advertisement and use of the SMTP Extension SMTPUTF8 gradually became as ubiquitous as 8BITMIME. It would seem to me to be completely appropriate to update the MDN specification. However, dealing with the i18n work by saying "Application that need to convey non ASCII text in these fields should consider implementing message/global-disposition-notification media type specified in [RFC6533] instead of this specification." (ignoring the grammatical errors in that sentence) seems to me to be completely contradictory to that transition theory and very confusing to implementers and operators of email systems as to what they should be doing. Asking them to implement and support two separate specifications for the same thing long-term --except possibly with different "generate" and "accept" models as pioneered for email by RFC 2822/5322-- is, at best, unwise on the part of the IETF. The relationship between this draft and RFC 6533 raises at least two other issues. First, RFC 6533 is heavily dependent on RFC 3798. it appears to me that several of the changes made in this document interact with 6533 as well and that either it needs to be updated to reflect them (and presumably to reference this document rather than 3798) or or it needs to be made very clear that the dependencies on 3798 from 6533 do not shift to this document (and how inconsistencies in registry instructions, etc., are to be resolved). Otherwise, we get back into the unresolved argument about what it means to have normative references to a document that has been obsoleted. Second, questions have been raised in separate discussions about the complexity and implementability of 6533, some of which questions reflect on 3798. The latter are not addressed by this document. It seems to me that it is inappropriate to advance this document before those relationship issues are carefully and openly explored and discussed. While the two sets of documents (EAI-produced and this AppsAWG work) all lie within the same Area and, for MDNs, even have overlapping authorship, coordination among the various pieces of work so far makes it seem much closer to a cross-area situation, so I think it is up to the leadership of the present group and the AD(s) to decide whether it is best to hold that discussion now or on IETF LC. best, john p.s. I will forward a copy of this note to the EAI list for information, but hope we can keep the discussion here on apps-discuss. --On Wednesday, August 03, 2016 19:58 -0700 "Murray S. Kucherawy" wrote: > https://www.ietf.org/rfcdiff?url1=draft-ietf-appsawg-mdn-3798b > is-02&url2=draft-ietf-appsawg-mdn-3798bis-10 > > If you have any final comments please provide them to the > list, the chair, or the authors ASAP. > > -MSK > > > ---------- Forwarded message ---------- > From: > Date: Sun, Jul 31, 2016 at 10:23 AM > Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the ART Area General Applications > Working Group of the IETF. > > Title : Message Disposition Notification > Authors : Tony Hansen > Alexey Melnikov > Filename : draft-ietf-appsawg-mdn-3798bis-09.txt > Pages : 35 > Date : 2016-07-31 > > Abstract: > This memo defines a MIME content-type that may be used by a > mail user agent (MUA) or electronic mail gateway to report > the disposition of a message after it has been successfully > delivered to a recipient. This content-type is intended to > be machine-processable. Additional message header fields > are also defined to permit Message Disposition > Notifications (MDNs) to be requested by the sender of a > message. The purpose is to extend Internet Mail to support > functionality often found in other messaging systems, such > as X.400 and the proprietary "LAN-based" systems, and often > referred to as "read receipts," "acknowledgements", or > "receipt notifications." The intention is to do this while > respecting privacy concerns, which have often been > expressed when such functions have been discussed in the past. > > Because many messages are sent between the Internet and > other messaging systems (such as X.400 or the proprietary > "LAN-based" systems), the MDN protocol is designed to be > useful in a multi- protocol messaging environment. To this > end, the protocol described in this memo provides for the > carriage of "foreign" addresses, in addition to those > normally used in Internet Mail. Additional attributes may > also be defined to support "tunneling" of foreign > notifications through Internet Mail. From nobody Thu Aug 4 07:42:59 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0CE12DA49; Thu, 4 Aug 2016 07:42:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160804144254.15916.12558.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 07:42:54 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 14:42:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-11.txt Pages : 36 Date : 2016-08-04 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 4 08:13:20 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C1A12D0A5 for ; Thu, 4 Aug 2016 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 c9pvwKJEdcMo for ; Thu, 4 Aug 2016 08:13:16 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id BCCC212B013 for ; Thu, 4 Aug 2016 08:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470323593; d=isode.com; s=june2016; i=@isode.com; bh=xmmE3VQ4/ASzF/34zyoqfY7s/ykyEPTQjuWkHxtQgT8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ci/x4NO2qAljLpzzaTropuTRYn9ly8qggABzTHVc9CfZCGAgxOZkhw45PhDnl8J2wQm1TR Mzgx7bArdkxtc1Yt5X71Zl+ZlF2jeMriSgVXXjbrjq404ld9VOSb3xQCB3XGk465TehQ4t GVrnlikiGXZoI3bWGIR3tq4TpDOdCT8=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 4 Aug 2016 16:13:13 +0100 To: John C Klensin , "Murray S. Kucherawy" , IETF Apps Discuss References: From: Alexey Melnikov Message-ID: Date: Thu, 4 Aug 2016 16:12:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 15:13:18 -0000 Hi John, I am still thinking on some of the issues that you've raised. Quick answers below. On 04/08/2016 15:14, John C Klensin wrote: > Murray, Tony, and Alexey, > > I don't know how to think about this draft in context, but my > problem is not with the specific changes to 3798. > > We've got Proposed Standards for internationalized headers and > addresses from the EAI WG (RFC 6530ff) that include an i18n MDN > specification (RFC 6533). One of the arguments against doing or > standardizing that work at all was that it basically created a > fork in the email environment with mutually-incompatible > ASCII-only (including encoded words, etc.) and i18n-native > environments. When the WG and IETF adopted the SMPTUTF8 ("EAI") > specifications as Proposed Standards, most of those who were > actively involved knew that the only basis on which the > situation they created would be viable long-term was if it was > transitional to fully-internationalized mail and that > advertisement and use of the SMTP Extension SMTPUTF8 gradually > became as ubiquitous as 8BITMIME. > > It would seem to me to be completely appropriate to update the > MDN specification. However, dealing with the i18n work by > saying > > "Application that need to convey non ASCII text in these > fields should consider implementing > message/global-disposition-notification media type > specified in [RFC6533] instead of this specification." > > (ignoring the grammatical errors in that sentence) seems to me > to be completely contradictory to that transition theory and > very confusing to implementers and operators of email systems as > to what they should be doing. Asking them to implement and > support two separate specifications for the same thing long-term > --except possibly with different "generate" and "accept" models > as pioneered for email by RFC 2822/5322-- is, at best, unwise on > the part of the IETF. > > The relationship between this draft and RFC 6533 raises at least > two other issues. First, RFC 6533 is heavily dependent on RFC > 3798. it appears to me that several of the changes made in this > document interact with 6533 as well and that either it needs to > be updated to reflect them (and presumably to reference this > document rather than 3798) Yes, good point. I will work on initial rfc6533-bis that addresses similar concerns. I am likely to delegate further editing of this future draft to another willing person. > or or it needs to be made very clear > that the dependencies on 3798 from 6533 do not shift to this > document (and how inconsistencies in registry instructions, > etc., are to be resolved). Otherwise, we get back into the > unresolved argument about what it means to have normative > references to a document that has been obsoleted. Second, > questions have been raised in separate discussions about the > complexity and implementability of 6533, Yes. I am still trying to figure out what is the best way forward on this. I will reread Arnt's proposal and will reply. > some of which questions > reflect on 3798. I am not sure about this, just yet. There might be no changes. > The latter are not addressed by this document. > It seems to me that it is inappropriate to advance this document > before those relationship issues are carefully and openly > explored and discussed. While the two sets of documents > (EAI-produced and this AppsAWG work) all lie within the same > Area and, for MDNs, even have overlapping authorship, > coordination among the various pieces of work so far makes it > seem much closer to a cross-area situation, so I think it is up > to the leadership of the present group and the AD(s) to decide > whether it is best to hold that discussion now or on IETF LC. Will you be Ok with having rfc6533-bis draft and some broad agreement between authors about the possible way forward with it? My preference is to get draft-ietf-appsawg-mdn-3798bis done (I would like to free up my time to do other IETF things) and proceed with rfc6533-bis in parallel. > best, > john > > p.s. I will forward a copy of this note to the EAI list for > information, but hope we can keep the discussion here on > apps-discuss. Thank you. Alexey > --On Wednesday, August 03, 2016 19:58 -0700 "Murray S. > Kucherawy" wrote: > >> https://www.ietf.org/rfcdiff?url1=draft-ietf-appsawg-mdn-3798b >> is-02&url2=draft-ietf-appsawg-mdn-3798bis-10 >> >> If you have any final comments please provide them to the >> list, the chair, or the authors ASAP. >> >> -MSK >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Jul 31, 2016 at 10:23 AM >> Subject: I-D Action: draft-ietf-appsawg-mdn-3798bis-09.txt >> To: i-d-announce@ietf.org >> Cc: apps-discuss@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the ART Area General Applications >> Working Group of the IETF. >> >> Title : Message Disposition Notification >> Authors : Tony Hansen >> Alexey Melnikov >> Filename : draft-ietf-appsawg-mdn-3798bis-09.txt >> Pages : 35 >> Date : 2016-07-31 >> >> Abstract: >> This memo defines a MIME content-type that may be used by a >> mail user agent (MUA) or electronic mail gateway to report >> the disposition of a message after it has been successfully >> delivered to a recipient. This content-type is intended to >> be machine-processable. Additional message header fields >> are also defined to permit Message Disposition >> Notifications (MDNs) to be requested by the sender of a >> message. The purpose is to extend Internet Mail to support >> functionality often found in other messaging systems, such >> as X.400 and the proprietary "LAN-based" systems, and often >> referred to as "read receipts," "acknowledgements", or >> "receipt notifications." The intention is to do this while >> respecting privacy concerns, which have often been >> expressed when such functions have been discussed in the past. >> >> Because many messages are sent between the Internet and >> other messaging systems (such as X.400 or the proprietary >> "LAN-based" systems), the MDN protocol is designed to be >> useful in a multi- protocol messaging environment. To this >> end, the protocol described in this memo provides for the >> carriage of "foreign" addresses, in addition to those >> normally used in Internet Mail. Additional attributes may >> also be defined to support "tunneling" of foreign >> notifications through Internet Mail. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Aug 4 09:11:21 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B5D12B007 for ; Thu, 4 Aug 2016 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 vwNNMt1PVO3m for ; Thu, 4 Aug 2016 09:11:17 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9D512D5EB for ; Thu, 4 Aug 2016 09:11:15 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bVLEm-000AV7-RK; Thu, 04 Aug 2016 12:11:12 -0400 Date: Thu, 04 Aug 2016 12:11:07 -0400 From: John C Klensin To: Alexey Melnikov Message-ID: <47872C0B5B5198E8126F5469@JcK-HP8200> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 16:11:20 -0000 Alexey, Some quick responses below (I'm on a call and about to head to a meeting... might change my mind with more thought)... --On Thursday, August 04, 2016 16:12 +0100 Alexey Melnikov wrote: >... >> It seems to me that it is inappropriate to advance this >> document before those relationship issues are carefully and >> openly explored and discussed. While the two sets of >> documents (EAI-produced and this AppsAWG work) all lie within >> the same Area and, for MDNs, even have overlapping authorship, >> coordination among the various pieces of work so far makes it >> seem much closer to a cross-area situation, so I think it is >> up to the leadership of the present group and the AD(s) to >> decide whether it is best to hold that discussion now or on >> IETF LC. > Will you be Ok with having rfc6533-bis draft and some broad > agreement between authors about the possible way forward with > it? My preference is to get draft-ietf-appsawg-mdn-3798bis > done (I would like to free up my time to do other IETF things) > and proceed with rfc6533-bis in parallel. Makes me _very_ nervous, especially against the background of some things being handled on the basis of such agreements and then having the revised document stall for nearly forever. I really do see a threat to SMTPUTF8 deployment and adoption in this work and way of handling things. Questions of how serious that threat is and whether it is acceptable really should be matters of community consensus (including the EAI community), not just an agreement among authors. If your goal is simply to get this out of your queue (something with which I'm very sympathetic), then post rfc6533-bis, if necessary even with placeholder content, put a normative reference to it in 3798bis, process the latter and then let it sit in the RFC Editor queue until we have actually addressed the issues. The is noot my favorite approach, but is certainly a possibility. best, john From nobody Thu Aug 4 12:48:23 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F9512D7EC for ; Thu, 4 Aug 2016 12:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 QhAr9EcLZhw3 for ; Thu, 4 Aug 2016 12:48:20 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0109.outbound.protection.outlook.com [104.47.41.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3733C12D7E3 for ; Thu, 4 Aug 2016 12:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wQYzo+IO+Xjvy0ANIGezJVNvlUd9BEu2QGGsXK8qdmg=; b=F/id64VB825iXM3h7raSesFt6fnFccd3Ek9PE438Eordr+4GXYUmlaouxvpXGEfCU4bhUvBphRWN+fq4E8slCL1Cqr6DAB7PetdG1Jo3VoO0EkJ2D4SeJejhxM44r1nu2UWU1K9WCfnFJTwlh/v2YQb6d+VelnR9ifaqBFAWUPU= Received: from CY4PR03MB2744.namprd03.prod.outlook.com (10.173.38.10) by CY4PR03MB2744.namprd03.prod.outlook.com (10.173.38.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 4 Aug 2016 19:48:17 +0000 Received: from CY4PR03MB2744.namprd03.prod.outlook.com ([10.173.38.10]) by CY4PR03MB2744.namprd03.prod.outlook.com ([10.173.38.10]) with mapi id 15.01.0549.023; Thu, 4 Aug 2016 19:48:17 +0000 From: Shawn Steele To: "apps-discuss@ietf.org" Thread-Topic: Confused about draft-ietf-appsawg-mdn-3798bis-11.txt Thread-Index: AdHuiKUhm5GAAtbwSw+fzH9gzCSaBA== Date: Thu, 4 Aug 2016 19:48:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-originating-ip: [2001:4898:80e8:9::b2] x-ms-office365-filtering-correlation-id: 8324e9e4-e578-4496-9fca-08d3bca04809 x-microsoft-exchange-diagnostics: 1; CY4PR03MB2744; 6:wLtiYaRebOSJHQdR2F0Ic5LAliLtWVqVQhml8e0LwQQ9EqUfZY72VdEjYlK5JsbdrSpGDucRsSHqn/m2YdmH1dsd5dBmkj5MZLC1RH5tZMrilwQb/NWZMAS/56dvu1MC9nT6jcmPrWNDzRkeRYirQ4dHXRmbybAoEwfN/LMCqpfkUaxEawW3v38tZavBN8bjNnv5bO2ZBx3Cq2ODSpOcAm4hIMTn1/ybynBeezfnqDUXJLXK/HyZoR/B2lFoHfjpMuCrlb8aGrGDBaDS0n7PX3Qxbk4tlQ1v8JSIbWP9b85NxZfd6eNgGTOOvjEhbq6HvBr8GI2UiAymwA1WvTWCQw==; 5:6lywKCNvB4Y3IGvZdI8IdwFC65mSHJjvMgQauUUQxlrhdWUHJauObso0eXeK6q7jmAnKku9jKWEzchl3Dnpc7xhEDQTEnMNbWgptFcvAdQ8PRAgT0cc4tbcjhj1tmp1rua0jEMoLz9OQjl8RB8gfFg==; 24:TWG/+rpxLZFm6066fhshaPZ9Vp+Kkbs60vNwmjgQKRw/OYUdufZCPZUC3im7yb8HxPgYonXwXYjHGJW+u2kYGghy3Ru6YCYWRPYIMlund7Y=; 7:qhf38eLO8yBw1fEeCN46VQDc1kN8pnmKXMUjXTswvkLR+su13vM1JcoOLXP97CY+ju8OkCNpoUVCk3tivuQXUGdkAbM1lUX1+Xk/6YQRXC+jNz18oI2YNAE27DJjIb0WBjpTfjJ8EpCCRUq3nxoohb0pvlZmu9mFySMUC+U3YSb5gFhRfS3cV+ifrbdZS6Nl3uoIiJiGO5GmWiKTDRV76sEIjOunnOIQCY53TXZBQo3+DkEZbbYBVCOQOsRI69V4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR03MB2744; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721)(21748063052155)(194585677185034); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY4PR03MB2744; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2744; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(230783001)(86362001)(19300405004)(97736004)(105586002)(99286002)(8936002)(5002640100001)(50986999)(19617315012)(81166006)(8676002)(19625215002)(2900100001)(101416001)(54356999)(81156014)(77096005)(2351001)(76576001)(16601075003)(107886002)(110136002)(16236675004)(2501003)(33656002)(106356001)(10290500002)(86612001)(5005710100001)(10400500002)(15975445007)(189998001)(8990500004)(229853001)(19580395003)(122556002)(7696003)(7846002)(7736002)(450100001)(74316002)(10090500001)(7906003)(6116002)(790700001)(102836003)(9686002)(87936001)(586003)(92566002)(5630700001)(5640700001)(11100500001)(3280700002)(68736007)(3660700001)(2906002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2744; H:CY4PR03MB2744.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR03MB2744D9D6CD59BBBC9F5C6B6082070CY4PR03MB2744namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2016 19:48:17.6969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2744 Archived-At: Subject: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 19:48:22 -0000 --_000_CY4PR03MB2744D9D6CD59BBBC9F5C6B6082070CY4PR03MB2744namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkcmFmdCBqdXN0IGNhbWUgdG8gbXkgYXR0ZW50aW9uLCBzbyBJ4oCZbSBwcm9iYWJseSBt aXNzaW5nIGEgdG9uIG9mIGludGVyZXN0aW5nIGNvbnRleHQsIGJ1dCBJIGhhdmUgYSBjb3VwbGUg cXVlc3Rpb25zL29ic2VydmF0aW9uczoNCg0KDQrCtyAgICAgICAgVGhpcyBpcyBhIG5ldyBtZWNo YW5pc20sIHNvIEnigJlkIHByZWZlciBpdCBiZSBkZXBlbmRlbnQgb24gb3RoZXIgbmV3IHRoaW5n cy4gIFN1Y2ggYXMgZGVwZW5kaW5nIG9uIFVURjhTTVRQIGluc3RlYWQgb2YgZGVzaWduaW5nIG90 aGVyIG1lY2hhbmlzbXMgZm9yIG5vbi1BU0NJSSBjb250ZW50LiAgSeKAmWQgZ28gc28gZmFyIGFz IHRvIHJlcXVpcmUgVVRGOFNNVFAgYXMgYSBwcmVyZXF1aXNpdGUuDQoNCsK3ICAgICAgICBJ4oCZ bSBjbGVhcmx5IG1pc3Npbmcgc29tZXRoaW5nICYgZ3JhbnRlZCBJIGRpZG7igJl0IHNwZW5kIGFs bCBkYXkgcmVhZGluZyBpdCwgYnV0IGhvdyBpcyB0aGlzIG5vdCBhIOKAnHllcywgbXkgc3BhbSBs aXN0IGhhcyBnb29kIGFkZHJlc3NlcyHigJ0gZmVhdHVyZT8NCg0KLSBTaGF3bg0KDQrvo6Lvo5Dv o6fvo5sg76Oi76Oj76OX76OU76OZDQpodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGU8aHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUy ZiUyZmJsb2dzLm1zZG4uY29tJTJmc2hhd25zdGUmZGF0YT0wMSU3YzAxJTdjU2hhd24uU3RlZWxl JTQwbWljcm9zb2Z0LmNvbSU3Yzg0ZTlhN2U5NDk0MjQ2MDdhYTdlMDhkMmRiMWFmNDM4JTdjNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTdnZVVXcWsyNlFYY3VUb2Jt b2ZzdVZBTUNGblZ2NUJSUExUMnJuUUJTTTQlM2Q+DQpodHRwOi8vYmItOC5ibG9nc3BvdC5jb208 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz YSUyZiUyZmJiLTguYmxvZ3Nwb3QuY29tJmRhdGE9MDElN2MwMSU3Y1NoYXduLlN0ZWVsZSU0MG1p Y3Jvc29mdC5jb20lN2M4NGU5YTdlOTQ5NDI0NjA3YWE3ZTA4ZDJkYjFhZjQzOCU3YzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1vMnI2ZTg0dmNYdmpPaU5rbUpQVTA5 NWZieU9JZEZUZXRZb2NaenFYUXU4JTNkPg0KDQo= --_000_CY4PR03MB2744D9D6CD59BBBC9F5C6B6082070CY4PR03MB2744namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ill1IEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA0IDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA WXUgR290aGljIjsNCglwYW5vc2UtMToyIDExIDQgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OnBJcWFEOw0KCXBhbm9zZS0xOjIgMCA2IDMgMCAwIDAgMCAwIDA7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA4MzYw MTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDYz MTU4OTEwIDEyMDAxMzU1MTggMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1Mjgz IDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NTt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUNBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBqdXN0IGNhbWUgdG8gbXkg YXR0ZW50aW9uLCBzbyBJ4oCZbSBwcm9iYWJseSBtaXNzaW5nIGEgdG9uIG9mIGludGVyZXN0aW5n IGNvbnRleHQsIGJ1dCBJIGhhdmUgYSBjb3VwbGUgcXVlc3Rpb25zL29ic2VydmF0aW9uczo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5UaGlzIGlzIGEgbmV3IG1lY2hhbmlzbSwgc28gSeKAmWQgcHJlZmVyIGl0IGJlIGRl cGVuZGVudCBvbiBvdGhlciBuZXcgdGhpbmdzLiZuYnNwOyBTdWNoIGFzIGRlcGVuZGluZyBvbiBV VEY4U01UUCBpbnN0ZWFkIG9mIGRlc2lnbmluZyBvdGhlciBtZWNoYW5pc21zIGZvciBub24tQVND SUkgY29udGVudC4mbmJzcDsgSeKAmWQgZ28gc28gZmFyIGFzIHRvIHJlcXVpcmUgVVRGOFNNVFAg YXMgYSBwcmVyZXF1aXNpdGUuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3lt Ym9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SeKAmW0g Y2xlYXJseSBtaXNzaW5nIHNvbWV0aGluZyAmYW1wOyBncmFudGVkIEkgZGlkbuKAmXQgc3BlbmQg YWxsIGRheSByZWFkaW5nIGl0LCBidXQgaG93IGlzIHRoaXMgbm90IGEg4oCceWVzLCBteSBzcGFt IGxpc3QgaGFzIGdvb2QgYWRkcmVzc2VzIeKAnSBmZWF0dXJlPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUNB Ij4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tQ0EiPiBTaGF3bjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OnBJcWFEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpwSXFhRDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpwSXFhRDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1DQSI+76Oi76OQ76On76ObIO+jou+jo++jl++jlO+jmTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUNBIj48YSBocmVmPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYmxvZ3MubXNk bi5jb20lMmZzaGF3bnN0ZSZhbXA7ZGF0YT0wMSU3YzAxJTdjU2hhd24uU3RlZWxlJTQwbWljcm9z b2Z0LmNvbSU3Yzg0ZTlhN2U5NDk0MjQ2MDdhYTdlMDhkMmRiMWFmNDM4JTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT03Z2VVV3FrMjZRWGN1VG9ibW9mc3VW QU1DRm5WdjVCUlBMVDJyblFCU000JTNkIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0 cDovL2Jsb2dzLm1zZG4uY29tL3NoYXduc3RlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLUNBIj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYmItOC5ibG9nc3BvdC5jb20m YW1wO2RhdGE9MDElN2MwMSU3Y1NoYXduLlN0ZWVsZSU0MG1pY3Jvc29mdC5jb20lN2M4NGU5YTdl OTQ5NDI0NjA3YWE3ZTA4ZDJkYjFhZjQzOCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZhbXA7c2RhdGE9bzJyNmU4NHZjWHZqT2lOa21KUFUwOTVmYnlPSWRGVGV0WW9jWnpx WFF1OCUzZCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHA6Ly9iYi04LmJsb2dzcG90 LmNvbTwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR03MB2744D9D6CD59BBBC9F5C6B6082070CY4PR03MB2744namp_-- From nobody Thu Aug 4 13:27:58 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA75712D7FC for ; Thu, 4 Aug 2016 13:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 KEoK64esPXMp for ; Thu, 4 Aug 2016 13:27:55 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BC012D800 for ; Thu, 4 Aug 2016 13:27:52 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bVPF8-000B8S-UZ; Thu, 04 Aug 2016 16:27:50 -0400 Date: Thu, 04 Aug 2016 16:27:45 -0400 From: John C Klensin To: Shawn Steele Message-ID: <65CD4EEE481E0F48F4DD6EE5@JcK-HP8200> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 20:27:57 -0000 Shawn, Thanks for taking a look. A clarification or two below in the hope of saving time.... --On Thursday, August 04, 2016 19:48 +0000 Shawn Steele wrote: > This draft just came to my attention, so I'm probably > missing a ton of interesting context, but I have a couple > questions/observations: >=20 >=20 > =C2=B7 This is a new mechanism, so I'd prefer it be > dependent on other new things. Such as depending on UTF8SMTP > instead of designing other mechanisms for non-ASCII content. > I'd go so far as to require UTF8SMTP as a prerequisite. I don't see this as a new mechanism, so much as tuning of the original MDN specifications through RFC 3798. The SMTPUTF8 (remember we switched the term around to distinguish the standards-track machinery from the earlier experimental specs) MDN machinery, described in RFC 6533, is very much dependent on and, IMO, evolutionary from, 3798. That said, I'm quite concerned about our going, instead of a path like the one you are suggesting which I see as 3798 -> 6533 -> maybe 6533bis -> unified MDN spec to 3798 -> 6533 -> eventual 6533bis \ -> 3798bis -> ... and would see an SMTPUTF8 prerequisite to unified MDNs, or at least a unified MDN model that didn't require handling separate from SMTPUTF8/6533[bis?], as highly desirable in that regard. See my longer note from earlier today for one view of the details. >... best, john From nobody Thu Aug 4 13:50:50 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79DA12D81B for ; Thu, 4 Aug 2016 13:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 VnZv2fVMEI_c for ; Thu, 4 Aug 2016 13:50:45 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3174212D821 for ; Thu, 4 Aug 2016 13:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1769; q=dns/txt; s=iport; t=1470343845; x=1471553445; h=from:subject:to:message-id:date:mime-version; bh=SSr/3XrLrh5madGAyJ3KYu7VUt8B9ocz6flNeFsHnB0=; b=WHRkm8mouzmdzVs5pReR2kGMjLycqI50Ja1NRladMRV/rQfEo+k0uerg +LWaSozSK7pjaVCW2LkoUMT5KX7qxPOLff3cwdqRN1A9LgXChhe/OEdN2 M1uwjLf+uPDt+DagCqxH1At6p8d0DeqOS4GcBpI2KBLxRMFypoWnzc+Kb Y=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqBwDgqaNX/5JdJa1dg0VWKlKkHQEBA?= =?us-ascii?q?QEBBpR9gX0khS+CFDoSAQEBAQEBAV0nhGAGASFLaAIpQwYCAQGILQ6eeo9jkAs?= =?us-ascii?q?jCQWFYoJAh2GCNYJaBY8MiiYCgzqBcolWgVUWhFuDDoVskCglAi2EGR0yhysBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.28,471,1464652800"; d="asc'?scan'208";a="306127615" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2016 20:50:44 +0000 Received: from [10.129.24.61] ([10.129.24.61]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u74KohUC008936 for ; Thu, 4 Aug 2016 20:50:44 GMT From: Matt Miller To: apps-discuss@ietf.org Message-ID: <2e9075da-cfc9-86d6-120c-0f72badca2d8@cisco.com> Date: Thu, 4 Aug 2016 14:50:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9LD8EBh0LHFEKuNTGVUiQcrQhjJttfVrh" Archived-At: Subject: [apps-discuss] Ledger Mailing List + BoF Minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 20:50:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9LD8EBh0LHFEKuNTGVUiQcrQhjJttfVrh Content-Type: multipart/mixed; boundary="prQtcnUH2FNP0FH0vk4FKskQbHMtbuGab" From: Matt Miller To: apps-discuss@ietf.org Message-ID: <2e9075da-cfc9-86d6-120c-0f72badca2d8@cisco.com> Subject: Ledger Mailing List + BoF Minutes --prQtcnUH2FNP0FH0vk4FKskQbHMtbuGab Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello all, We now have a mailing list at < https://www.ietf.org/mailman/listinfo/ledger >. Please use this mailing list instead of apps-discuss@. The minutes for the Ledger BoF have been posted at < https://www.ietf.org/proceedings/96/minutes/minutes-96-ledger >. Please send any corrections to the mailing list < ledger@ietf.org > or to the Chairs < ledger-chairs@ietf.org > as soon as possible. Thanks again to our minute takers and Jabber scribes! -- - Adam and Matt --prQtcnUH2FNP0FH0vk4FKskQbHMtbuGab-- --9LD8EBh0LHFEKuNTGVUiQcrQhjJttfVrh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXo6qjAAoJEDWi+S0W7cO1iTEH/0NxBuLi0ORrLKsdlo3NXTtC Hf+rWrzu6ygLUPVH39VcOB0281QqqE/9wPSqJ9lPLVR3ICVhRM/SSntUMe2DHBF/ oyUoalTb92RBkC02xKSLYyLVM+ZMp8Kc/gOGupiPkm2VhtsEEVfDG9Yrp8q3Cd+D vDvXs/dX7KHHN5axLK0gk6J8Yq1hzqbW9qOCv4of+Esih7sq0peAD4PpzzhV0G4x rJ4m/wmyVyV1vKWujzGiWqSm9G9sgjmZoV3euoVXpptdrGH1hOL9pi41DrwXjyx9 vxJauXYrln8zbzdLKYiPYKmm0NJYC3tEDqyUlR3BUeWGViGycd5ZjFuruWPVRns= =sY21 -----END PGP SIGNATURE----- --9LD8EBh0LHFEKuNTGVUiQcrQhjJttfVrh-- From nobody Thu Aug 4 14:06:05 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD512D81B for ; Thu, 4 Aug 2016 14:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 zerBKAI2KZgh for ; Thu, 4 Aug 2016 14:06:02 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0132.outbound.protection.outlook.com [104.47.38.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D27812D78E for ; Thu, 4 Aug 2016 14:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GmG95G7dhU6OWjs4PoRzjVvStpGGEh9LMUXHO2qL9Qs=; b=cLCc30fUP6+Jz/BGNPGyK0sDyOoGysltZWAot4lzPY1RryV8X1s321PTwCf3bw3KQIHynTsbIp+x2B6pXis+QyCXZSVXtLeLBqYpoiinyTFWdQwncrXWvM+AyVHNGSV62W/3b+kx7KUY5yrwIT+6pTIAd+jjFoae2EPz4i57RRg= Received: from CY4PR03MB2744.namprd03.prod.outlook.com (10.173.38.10) by CY4PR03MB2742.namprd03.prod.outlook.com (10.173.38.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 4 Aug 2016 21:05:59 +0000 Received: from CY4PR03MB2744.namprd03.prod.outlook.com ([10.173.38.10]) by CY4PR03MB2744.namprd03.prod.outlook.com ([10.173.38.10]) with mapi id 15.01.0549.023; Thu, 4 Aug 2016 21:05:59 +0000 From: Shawn Steele To: John C Klensin Thread-Topic: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt Thread-Index: AdHuiKUhm5GAAtbwSw+fzH9gzCSaBAABgNeAAAE7TwA= Date: Thu, 4 Aug 2016 21:05:59 +0000 Message-ID: References: <65CD4EEE481E0F48F4DD6EE5@JcK-HP8200> In-Reply-To: <65CD4EEE481E0F48F4DD6EE5@JcK-HP8200> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-originating-ip: [2001:4898:80e8:9::b2] x-ms-office365-filtering-correlation-id: 5767bcd4-c35b-4a43-17e0-08d3bcab2295 x-microsoft-exchange-diagnostics: 1; CY4PR03MB2742; 6:a2f5bTnqH7xbLbjvGHFVzD+r0HoUB4f0Ce5Dx/2QxYyKGd0TdYIUxq1Dsx9zbeHl2bFF6scyToTbpHDti/6hag68kVDoDBnxKmhHgWDdCeS+7gGa9HBnM1Iuo7fcDxkZKTCxraoMMPL3JR8+Oxl1EAsNiDO2fHZxOsoWrUU9zxHCvI5YVLt/mYqtrRh25uIc59NwQNL+g91B+G0y82/v2FCNTThL7Hj0iDbt3tV3vYkK5JTltlEXzyo+hnohORh5MMIAwm72ALzGhXgXs8YMxXF39yVyEvYuUoMw5wFUytSKdGSAAEUdFQPdXHFRH3AMHaFYeePksqaqcyPW20Chdw==; 5:MlWl/3PcTyYMeq4Om7yYcdCQfAHcpnHSUrzV5okGi8OQ4FUB4srl41NWkkC8ooaeDhmGW6131OEhI27GlKPPr4fCCASP0W+f/fK+h8Itk+4FlcAktKNWgfGN6IA32pEKwc8dXeIllumgBIG8dOfPuA==; 24:s2EZUrlfUHf5Ez06UeM+vNXlOxOR8r0m31HagjZOrcq5CAIZNX+oA2Ogp24WT9nEhRxCD2pj3lkas8n9KB+w6X2AYCqlZ4uxJsxS81SNcTM=; 7:dZFbshrmcvOdYwEb7q35UtWMPizosYW79zDL43Jc35YCSnZAhY+n7rXNe0N5bHn+MD68acRkM1KNR6fJmIgYfSVjTEOaiHdq8oQ9e5t2h/daj6EBCHrfC5yoJNJsSsTEWv+osvlbuLCxhwBIHjD6pHQW9gB1Rm3hb3meW6eli+DC/YubvRuNoIif++PJ+tkgJZU94OWLARXcp1FGK3aUGcVDPLfqPHinBhyc7LUXiZJZhFkVu9MAj4+3jhKsq8jN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR03MB2742; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY4PR03MB2742; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2742; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(52314003)(13464003)(189002)(9686002)(97736004)(8676002)(10090500001)(10400500002)(10290500002)(230783001)(5005710100001)(586003)(86612001)(68736007)(101416001)(5002640100001)(76176999)(92566002)(99286002)(3660700001)(8990500004)(81166006)(110136002)(11100500001)(81156014)(189998001)(54356999)(86362001)(105586002)(8936002)(50986999)(7696003)(74316002)(7736002)(102836003)(6116002)(77096005)(305945005)(2906002)(3280700002)(4326007)(2900100001)(2950100001)(7846002)(122556002)(106356001)(33656002)(87936001)(19580405001)(19580395003)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2742; H:CY4PR03MB2744.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2016 21:05:59.3186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2742 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 21:06:04 -0000 T2ssIG5ldyBwcm9iYWJseSB3YXNuJ3QgYSBncmVhdCBjaG9pY2UuICBVcGRhdGVkIGFueXdheSwg YW5kIEknZCByYXRoZXIgaXQgYnVpbGQgb2ZmIG9mIHRoZSBvdGhlciBtb3JlIHJlY2VudCB0aGlu a2luZyByYXRoZXIgdGhhbiBoYXZlIHRoZSBwb3RlbnRpYWwgZm9ya2VkIHBhdGguICBJdCdzIHdh eSBlYXNpZXIgdG8gc3VwcG9ydCBhbiBBICsgQiArIEMgc2NlbmFyaW8gdGhhbiBhbiBBLCBtYXli ZS1CLCBzb21ldGltZXMtQywgcGVyaGFwcyBhbGwgdGhyZWUgc2NlbmFyaW8uICANCg0KQWRkaXRp b25hbGx5IGl0IHdvdWxkIHNpbXBsaWZ5IHRoZSBzcGVjIChhbmQgdGh1cyB0aGUgaW1wbGVtZW50 YXRpb24pIGlmIHlvdSBjYW4gdGFrZSBTTVRQVVRGOCBhcyBhIHByZXJlcXVpc2l0ZSwgdGhlbiB5 b3UgY2FuIGdldCByaWQgb2YgdGhlIDctYml0IGFuZCBvdGhlciBjb21wYXQgc3R1ZmYuDQoNCi1T aGF3bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBDIEtsZW5zaW4g W21haWx0bzpqb2huLWlldGZAamNrLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDQsIDIw MTYgMTM6MjgNClRvOiBTaGF3biBTdGVlbGUgPFNoYXduLlN0ZWVsZUBtaWNyb3NvZnQuY29tPg0K Q2M6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIENv bmZ1c2VkIGFib3V0IGRyYWZ0LWlldGYtYXBwc2F3Zy1tZG4tMzc5OGJpcy0xMS50eHQNCg0KU2hh d24sDQoNClRoYW5rcyBmb3IgdGFraW5nIGEgbG9vay4gIEEgY2xhcmlmaWNhdGlvbiBvciB0d28g YmVsb3cgaW4gdGhlIGhvcGUgb2Ygc2F2aW5nIHRpbWUuLi4uDQoNCi0tT24gVGh1cnNkYXksIEF1 Z3VzdCAwNCwgMjAxNiAxOTo0OCArMDAwMCBTaGF3biBTdGVlbGUgPFNoYXduLlN0ZWVsZUBtaWNy b3NvZnQuY29tPiB3cm90ZToNCg0KPiBUaGlzIGRyYWZ0IGp1c3QgY2FtZSB0byBteSBhdHRlbnRp b24sIHNvIEknbSBwcm9iYWJseSBtaXNzaW5nIGEgdG9uIG9mIA0KPiBpbnRlcmVzdGluZyBjb250 ZXh0LCBidXQgSSBoYXZlIGEgY291cGxlDQo+IHF1ZXN0aW9ucy9vYnNlcnZhdGlvbnM6DQo+IA0K PiANCj4gwrcgICAgICAgIFRoaXMgaXMgYSBuZXcgbWVjaGFuaXNtLCBzbyBJJ2QgcHJlZmVyIGl0 IGJlDQo+IGRlcGVuZGVudCBvbiBvdGhlciBuZXcgdGhpbmdzLiAgU3VjaCBhcyBkZXBlbmRpbmcg b24gVVRGOFNNVFAgaW5zdGVhZCANCj4gb2YgZGVzaWduaW5nIG90aGVyIG1lY2hhbmlzbXMgZm9y IG5vbi1BU0NJSSBjb250ZW50Lg0KPiBJJ2QgZ28gc28gZmFyIGFzIHRvIHJlcXVpcmUgVVRGOFNN VFAgYXMgYSBwcmVyZXF1aXNpdGUuDQoNCkkgZG9uJ3Qgc2VlIHRoaXMgYXMgYSBuZXcgbWVjaGFu aXNtLCBzbyBtdWNoIGFzIHR1bmluZyBvZiB0aGUgb3JpZ2luYWwgTUROIHNwZWNpZmljYXRpb25z IHRocm91Z2ggUkZDIDM3OTguICBUaGUgU01UUFVURjggKHJlbWVtYmVyIHdlIHN3aXRjaGVkIHRo ZSB0ZXJtIGFyb3VuZCB0byBkaXN0aW5ndWlzaCB0aGUgc3RhbmRhcmRzLXRyYWNrIG1hY2hpbmVy eSBmcm9tIHRoZSBlYXJsaWVyIGV4cGVyaW1lbnRhbCBzcGVjcykgTUROIG1hY2hpbmVyeSwgZGVz Y3JpYmVkIGluIFJGQyA2NTMzLCBpcyB2ZXJ5IG11Y2ggZGVwZW5kZW50IG9uIGFuZCwgSU1PLCBl dm9sdXRpb25hcnkgZnJvbSwgMzc5OC4NCg0KVGhhdCBzYWlkLCBJJ20gcXVpdGUgY29uY2VybmVk IGFib3V0IG91ciBnb2luZywgaW5zdGVhZCBvZiBhIHBhdGggbGlrZSB0aGUgb25lIHlvdSBhcmUg c3VnZ2VzdGluZyB3aGljaCBJIHNlZSBhcw0KDQogICAzNzk4IC0+IDY1MzMgLT4gbWF5YmUgNjUz M2JpcyAtPiB1bmlmaWVkIE1ETiBzcGVjDQoNCnRvDQoNCiAgIDM3OTggLT4gNjUzMyAtPiBldmVu dHVhbCA2NTMzYmlzDQogICAgICAgIFwNCiAgICAgICAgIC0+IDM3OThiaXMgLT4gLi4uDQoNCmFu ZCB3b3VsZCBzZWUgYW4gU01UUFVURjggcHJlcmVxdWlzaXRlIHRvIHVuaWZpZWQgTUROcywgb3Ig YXQgbGVhc3QgYSB1bmlmaWVkIE1ETiBtb2RlbCB0aGF0IGRpZG4ndCByZXF1aXJlIGhhbmRsaW5n IHNlcGFyYXRlIGZyb20gU01UUFVURjgvNjUzM1tiaXM/XSwgYXMgaGlnaGx5IGRlc2lyYWJsZSBp biB0aGF0IHJlZ2FyZC4NClNlZSBteSBsb25nZXIgbm90ZSBmcm9tIGVhcmxpZXIgdG9kYXkgZm9y IG9uZSB2aWV3IG9mIHRoZSBkZXRhaWxzLg0KDQo+Li4uDQoNCmJlc3QsDQogICBqb2huDQoNCg== From nobody Thu Aug 4 15:20:39 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CA912D890 for ; Thu, 4 Aug 2016 15:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 zuZU_skpMtxJ for ; Thu, 4 Aug 2016 15:20:36 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C69C12D863 for ; Thu, 4 Aug 2016 15:20:36 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bVR0E-000BKp-Sk; Thu, 04 Aug 2016 18:20:34 -0400 Date: Thu, 04 Aug 2016 18:20:29 -0400 From: John C Klensin To: Shawn Steele Message-ID: In-Reply-To: References: <65CD4EEE481E0F48F4DD6EE5@JcK-HP8200> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 22:20:37 -0000 --On Thursday, August 04, 2016 21:05 +0000 Shawn Steele wrote: > Ok, new probably wasn't a great choice. Updated anyway, and > I'd rather it build off of the other more recent thinking > rather than have the potential forked path. It's way easier > to support an A + B + C scenario than an A, maybe-B, > sometimes-C, perhaps all three scenario. > > Additionally it would simplify the spec (and thus the > implementation) if you can take SMTPUTF8 as a prerequisite, > then you can get rid of the 7-bit and other compat stuff. Completely agree, modulo working out a plan that doesn't immediately make the vast majority of existing implementations non-conformant... or a community decision that is the best way to go anyway. Just wanted to be sure we were talking about the same thing, which we appear to be. best, john From nobody Thu Aug 4 21:09:44 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6759F12D1AE for ; Thu, 4 Aug 2016 21:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 E9bJCbf-2G5z for ; Thu, 4 Aug 2016 21:09:41 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D967212B05B for ; Thu, 4 Aug 2016 21:09:40 -0700 (PDT) Received: from [10.4.10.156] (unknown [IPv6:2001:984:aee9:104:7496:35ef:21df:a6a8]) by mail.frobbit.se (Postfix) with ESMTPSA id DF0C620344; Fri, 5 Aug 2016 06:09:38 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: dcrocker@bbiw.net Date: Fri, 05 Aug 2016 06:09:41 +0200 Message-ID: In-Reply-To: References: <40c227db-76ff-15bd-3358-ba85a63f1b59@gmail.com> <08FD5E91-BB1B-4190-AD00-5BE6505556D6@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_DEC6C2BF-E073-4D4E-AE55-E577542C6817_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6042) Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 04:09:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_DEC6C2BF-E073-4D4E-AE55-E577542C6817_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 4 Aug 2016, at 0:20, Dave Crocker wrote: > So finding a way to simplify this down to one table seems eminently rea= sonable. I think this is a very good goal, reachable, and NOT succeeding is someth= ing we should not decide upon lightly. paf --=_MailMate_DEC6C2BF-E073-4D4E-AE55-E577542C6817_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlekEYUACgkQrMabGguI181MHACfcD6BTOLhnj/3v2X27Ennw8Bq ykcAn2Wnhrja7zLZh51NiSFTLjAXQgM5 =Nqcz -----END PGP SIGNATURE----- --=_MailMate_DEC6C2BF-E073-4D4E-AE55-E577542C6817_=-- From nobody Thu Aug 4 22:29:07 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CD812D110 for ; Thu, 4 Aug 2016 22:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 H0bjnOgBuUHe for ; Thu, 4 Aug 2016 22:29:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 DA05012B029 for ; Thu, 4 Aug 2016 22:29:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q3D5TBQBO000DZCY@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 4 Aug 2016 22:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1470374637; bh=XFu4Bgu8PLg49MvddJhTicAW0LGd2ZQ8UvFGpnfx05c=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=SIQzBWAeRHn0J2hJoz4f8TKSqiklG9O1X6NS6jjnF9blzlVhhyqVQn7MFVfGiAJtB Tpr+CCnEGzr8eCKxiakZHICO7zspe1HCSKlECrz4gwCy3hWFuak/z43NsNvTJ8QDAJ bPS4mrso+ORDqbC9tkItaAqEDl0mQmyfQEVw9pZI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q2VYVWUFM800005M@mauve.mrochek.com>; Thu, 04 Aug 2016 22:23:56 -0700 (PDT) Message-id: <01Q3D5TAE7N000005M@mauve.mrochek.com> Date: Thu, 04 Aug 2016 22:23:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 03 Aug 2016 22:05:24 +0000" <20160803220524.59905.qmail@ary.lan> References: <40c227db-76ff-15bd-3358-ba85a63f1b59@gmail.com> <20160803220524.59905.qmail@ary.lan> To: John Levine Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 05:29:06 -0000 > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ > >We think the Apps area will have a vested interest in not only the > >registry, but ensuring all current applications are documented. We > >welcome any and all feedback > I still think this is long overdue. If anything, this is an understatement. > Is anyone else interested? Absolutely. Ned From nobody Fri Aug 5 02:15:42 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9112D80B for ; Fri, 5 Aug 2016 02:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 U8tqlYU8KNl7 for ; Fri, 5 Aug 2016 02:15:39 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 909EE12D68F for ; Fri, 5 Aug 2016 02:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1470388537; d=isode.com; s=june2016; i=@isode.com; bh=cIvPq7LVzNT6XaOLhZWU90860osMBhXLYnSs7HlmrPU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=T/bd2O/1xP40eRvkT1L9dwbvJl1CQn2nvml+pGo1n2QCHlWlsNEiRY8ZZ3ZfFo9JjDFzPL DP+H7NKR7Hh8v1Q0+kur7+1GPFlzjHfpSYq0KLhTOyrL1Cf1udjSu+B5PUrz9tWRWRbFTM xe0fdhnLcpaPMrAzDoLdSjFCMCrLoGU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 5 Aug 2016 10:15:37 +0100 To: John C Klensin References: <47872C0B5B5198E8126F5469@JcK-HP8200> From: Alexey Melnikov Message-ID: Date: Fri, 5 Aug 2016 10:15:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <47872C0B5B5198E8126F5469@JcK-HP8200> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 09:15:41 -0000 Hi John, On 04/08/2016 17:11, John C Klensin wrote: > Alexey, > > Some quick responses below (I'm on a call and about to head to a > meeting... might change my mind with more thought)... > > --On Thursday, August 04, 2016 16:12 +0100 Alexey Melnikov > wrote: > >> ... >>> It seems to me that it is inappropriate to advance this >>> document before those relationship issues are carefully and >>> openly explored and discussed. While the two sets of >>> documents (EAI-produced and this AppsAWG work) all lie within >>> the same Area and, for MDNs, even have overlapping authorship, >>> coordination among the various pieces of work so far makes it >>> seem much closer to a cross-area situation, so I think it is >>> up to the leadership of the present group and the AD(s) to >>> decide whether it is best to hold that discussion now or on >>> IETF LC. >> Will you be Ok with having rfc6533-bis draft and some broad >> agreement between authors about the possible way forward with >> it? My preference is to get draft-ietf-appsawg-mdn-3798bis >> done (I would like to free up my time to do other IETF things) >> and proceed with rfc6533-bis in parallel. > Makes me _very_ nervous, especially against the background of > some things being handled on the basis of such agreements and > then having the revised document stall for nearly forever. I > really do see a threat to SMTPUTF8 deployment and adoption in > this work and way of handling things. Questions of how serious > that threat is and whether it is acceptable really should be > matters of community consensus (including the EAI community), > not just an agreement among authors. > > If your goal is simply to get this out of your queue (something > with which I'm very sympathetic), then post rfc6533-bis, Pretty much. There is no point in posting rfc6533-bis-00 if there is no tentative agreement between authors how to proceed (at the moment there isn't), but the intent is to let normal IETF process apply after that. Maybe even do this in a new WG. > if necessary even with placeholder content, put a normative > reference to it in 3798bis, process the latter and then let it > sit in the RFC Editor queue until we have actually addressed the > issues. The is noot my favorite approach, but is certainly a > possibility. This is not my preferred approach, considering that RFC 6533 is not as widely deployed as RFC 3798 (and its predecessors). Best Regards, Alexey From nobody Fri Aug 5 04:56:57 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECA912D198 for ; Fri, 5 Aug 2016 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 f-uPatWWsP5M for ; Fri, 5 Aug 2016 04:56:53 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 C5A4312D09F for ; Fri, 5 Aug 2016 04:56:53 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u75BsIFE039673; Fri, 5 Aug 2016 07:56:46 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 24mt55gxr8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2016 07:56:45 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75Buivx017526; Fri, 5 Aug 2016 07:56:45 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75BueuX017462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Aug 2016 07:56:42 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 5 Aug 2016 11:56:17 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.30]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 07:56:17 -0400 From: "HANSEN, TONY L" To: John Levine , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf Thread-Index: AQHR7xBfekruHD4CckaGXiJmggfDBQ== Date: Fri, 5 Aug 2016 11:56:16 +0000 Message-ID: References: <40c227db-76ff-15bd-3358-ba85a63f1b59@gmail.com> <20160803220524.59905.qmail@ary.lan> In-Reply-To: <20160803220524.59905.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.240.69] Content-Type: text/plain; charset="utf-8" Content-ID: <11BD0FE901BF1143A1E0B75B934A291D@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608050142 Archived-At: Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 11:56:56 -0000 TG9uZyBsb25nIG92ZXJkdWUNCg0KT24gOC8zLzE2LCA2OjA1IFBNLCAiYXBwcy1kaXNjdXNzIG9u IGJlaGFsZiBvZiBKb2huIExldmluZSIgPGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBqb2hubEB0YXVnaC5jb20+IHdyb3RlOg0KDQogICAgPglodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc29wLWF0dHJsZWFmLw0KICAgIA0KICAg ID5XZSB0aGluayB0aGUgQXBwcyBhcmVhIHdpbGwgaGF2ZSBhIHZlc3RlZCBpbnRlcmVzdCBpbiBu b3Qgb25seSB0aGUgDQogICAgPnJlZ2lzdHJ5LCBidXQgZW5zdXJpbmcgYWxsIGN1cnJlbnQgYXBw bGljYXRpb25zIGFyZSBkb2N1bWVudGVkLiAgV2UgDQogICAgPndlbGNvbWUgYW55IGFuZCBhbGwg ZmVlZGJhY2sNCiAgICANCiAgICBJIHN0aWxsIHRoaW5rIHRoaXMgaXMgbG9uZyBvdmVyZHVlLiAg SXMgYW55b25lIGVsc2UgaW50ZXJlc3RlZD8NCg0K From nobody Fri Aug 5 06:57:51 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F4B12D0AF for ; Fri, 5 Aug 2016 06:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 SAsUhLRf9MCD for ; Fri, 5 Aug 2016 06:57:47 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B578712D0BF for ; Fri, 5 Aug 2016 06:57:47 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bVfdA-000D3c-Tt; Fri, 05 Aug 2016 09:57:44 -0400 Date: Fri, 05 Aug 2016 09:57:39 -0400 From: John C Klensin To: Alexey Melnikov Message-ID: In-Reply-To: References: <47872C0B5B5198E8126F5469@JcK-HP8200> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Joseph Yee , Shawn Steele , IETF Apps Discuss Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 13:57:49 -0000 Alexey, (explicitly copying a few important/relevant people who may not be actively following this list) --On Friday, August 05, 2016 10:15 +0100 Alexey Melnikov wrote: >>> Will you be Ok with having rfc6533-bis draft and some broad >>> agreement between authors about the possible way forward with >>> it? My preference is to get draft-ietf-appsawg-mdn-3798bis >>> done (I would like to free up my time to do other IETF >>> things) and proceed with rfc6533-bis in parallel. >> Makes me _very_ nervous, especially against the background of >> some things being handled on the basis of such agreements and >> then having the revised document stall for nearly forever. I >> really do see a threat to SMTPUTF8 deployment and adoption in >> this work and way of handling things. Questions of how >> serious that threat is and whether it is acceptable really >> should be matters of community consensus (including the EAI >> community), not just an agreement among authors. >> If your goal is simply to get this out of your queue >> (something with which I'm very sympathetic), then post >> rfc6533-bis, > Pretty much. There is no point in posting rfc6533-bis-00 if > there is no tentative agreement between authors how to proceed > (at the moment there isn't), but the intent is to let normal > IETF process apply after that. Maybe even do this in a new WG. If you think you can get sufficient leadership and engagement, I think the community would benefit from a sort of YAM-bis to draw things back together. Especially if/when the discussion gets really technical, it would also move the work off this list, which I see as an advantage. However, for reasons very similar to Shawn's, I think the "EAI" work needs to be part of the drawing-together process. That applies not only to DSNs, but to questions such as whether we are ready to start aggressively pushing SMTPUTF8 and potentially discouraging the use of encoded-words (while still requiring that they be accepted and understood). If we are not, we are getting to be in desperate need of an Applicability Statement that is clear about what implementers and operators actually should do. See below. >> if necessary even with placeholder content, put a normative >> reference to it in 3798bis, process the latter and then let it >> sit in the RFC Editor queue until we have actually addressed >> the issues. The is noot my favorite approach, but is >> certainly a possibility. > This is not my preferred approach, considering that RFC 6533 > is not as widely deployed as RFC 3798 (and its predecessors). Not mine either but see Shawn's note, Arnt's comments, and so on. Creating a real or apparent long-term fork is in no one's interest. There is also the question of what one counts in the SMTPUTF8 space -- Joseph is more likely than I am to have details, but I believe we are above two independent interoperable implementation on all components, even though some of those implementations may not be fully conformant to the spec and whose experience may argue for dropping some requirements or features (again, see Arnt's notes, most of which have not been posted to this list). I don't know how to sort those issues out without considering everything in the same context... and it doesn't seem to me that advancing potentially-forking documents piecemeal is consistent with that. best, john From nobody Fri Aug 5 07:29:58 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465F212D1BE for ; Fri, 5 Aug 2016 07:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 Td6sJ95SvPAU for ; Fri, 5 Aug 2016 07:29:54 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C14512B037 for ; Fri, 5 Aug 2016 07:29:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 39CD3FA00F9; Fri, 5 Aug 2016 14:29:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1470407391; bh=9pAEWOixDqg7efsojFHuFLfGe8KVv6mefAKBfbDHH5c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iBmsHLoUjNnR4wyZE439KG4v1PV2pC24+4SgxKGSDEEiOLPH/CHkuCIS4zI8PzD+5 6DEAHqnuyqqQUeB1GpeovBL2jLYebbDJpS3iqpzpv1wxEg+mBvRhZn/MZxanS2x3ZR 0msPaD9sCEqWpxZElKEtDS0wJPhZ6kdl0xXq2KCI= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1470407390-8864-25249/12/232; Fri, 5 Aug 2016 14:29:50 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss Date: Fri, 5 Aug 2016 15:29:46 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.5 (jessie) Mime-Version: 1.0 Message-Id: <459e7377-b699-4f48-95f0-627a0501e916@gulbrandsen.priv.no> In-Reply-To: References: <47872C0B5B5198E8126F5469@JcK-HP8200> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 14:29:56 -0000 John C Klensin writes: > (again, see Arnt's notes, most of which have not been > posted to this list). I can sum up on the list, or perhaps restate. RFC 6533 is not a very long RFC, but it is bothersomely complicated, most of the complexity is not central to its purpose, and it's not being implemented as much as the neighbouring RFCs. The parts of that sentence are causally related, I think. I am proposing to replate 6533 with a simpler version. I want to simplify section 3 (about ORCPT) so that only the first two productions in the formal syntax are needed. (This affects what happens when the message path includes a standards violation. There is no change as long as the MTAs follows the RFCs.) I also want to simplify section 4.5 (DSN generation) so that it's possible to generate a DSN without reference to the DSN's recipient's SMTP server's SMTP extensions. If possible perhaps simplify a few other bits of section 4. I have volunteered to do the editing. I probably add an example or two while editing. IMO, 3798bis should incorporate what it needs from 6533(bis). Reading and implementing partly related documents is harder than it needs to. Separate documents is convenient for us, that's IMO less important than having implementers be able to read and understand. Arnt From nobody Fri Aug 5 10:10:15 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7512D926; Fri, 5 Aug 2016 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=HARm6TFZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=Vax7jZr4 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 u4IG_Sge0uU9; Fri, 5 Aug 2016 10:10:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801D12D925; Fri, 5 Aug 2016 10:10:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.54.237]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u75H9cNH026895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2016 10:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1470416993; x=1470503393; bh=ygXuS+OzoRvzTch5+NEn5gvIQ/BDwj3b4KWNJ5RL2zE=; h=Date:To:From:Subject:Cc; b=HARm6TFZjxby+ogFo7SwVojB/vB0/sBKsIENj9sDNpg3W6shkDBmtw+c5W6b0oBGz BHX96mzn+OOghR9Z9UgvfdAsNul6K8AY7Ax6OPtR13AP9nQ0uY3TmUhLTqmkINP71k 9BhcrABTdc5hUddqkCItc8nZIwosRYiQ2MjFzs+Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1470416993; x=1470503393; i=@elandsys.com; bh=ygXuS+OzoRvzTch5+NEn5gvIQ/BDwj3b4KWNJ5RL2zE=; h=Date:To:From:Subject:Cc; b=Vax7jZr4/lmP/SrY54vf307dy4oV2au675x9joNfloyG/Cbfw8/qnxZ0dkVZWWd1f PbbnprnzW8BOggZA/xG48aKQ2fROJWiZFV6TwCR8kRJ6QPrRUEJxYUH4vRwbsqbHCS J6JskBZ6oJ0GDP8FCqgzdMonTHSnefc0pv4bPP7Q= Message-Id: <6.2.5.6.2.20160805084142.0bd419e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 Aug 2016 09:49:54 -0700 To: apps-discuss@ietf.org, Lars Eggert , Godred Fairhurst , Greg Shepherd From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: iesg@ietf.org, tsvwg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 17:10:09 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tsvwg-rfc5405bis-16 Title: UDP Usage Guidelines Reviewer: S. Moonesamy Review Date: August 5, 2016 IETF Last Call Date: May 17, 2016 Summary: This draft is almost ready for publication as an Best Common Practice RFC. The document is applicable to application protocol designers instead of application developers as the recommendation about UDP would have to be part of the application protocol for ease of implementation. Major issues: None Minor issues: In Section 3.1.9: "Applications intended for the Internet SHOULD NOT assume that QoS mechanisms are supported by the networks they use, and therefore need to provide congestion control, error recovery, etc. in case the actual network path does not provide provisioned service." Is there a case when an application intended for use on the Internet can assume that QoS mechanisms are supported throughout both ends of the connection? Nits: In Section 1: "In such cases, it is RECOMMENDED that application designers cite the respective section(s) of this document in the technical specification of their application or protocol and explain their rationale for their design choice.' The RFC 2119 key word is used before its definition in Section 2. Regards, S. Moonesamy From nobody Sun Aug 7 05:43:02 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102F012D098 for ; Sun, 7 Aug 2016 05:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 JNy0_x13bzCK for ; Sun, 7 Aug 2016 05:42:58 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E51412B01C for ; Sun, 7 Aug 2016 05:42:57 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 520EEFA0078; Sun, 7 Aug 2016 12:42:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1470573775; bh=yy6H/x+gb+xtv00r+8J/B0ITxand8ZlD3/30xMRgHTo=; h=From:To:Subject:Date:References:From; b=H7SKGVaOlFi4EoVc/SMDp5IAjsmceWGt4KN7vZtO4YMIJ66MLJ1cxNYITba7x+R39 P0Mkgw5qu+E9U2UBNNCfYLUon+NNmAPO+MEOF9slLEr+++K1inucRx3ubptzeKBhiM AMH0D3M8J081QwXqt0F4S7G7wmPcv6neOCF7Emow= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1470573774-25251-25249/12/538; Sun, 7 Aug 2016 12:42:54 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Sun, 7 Aug 2016 16:42:51 +0400 Message-Id: <8KrqSn+R2axy3201Jg39KsR/UFJb0VQwKmwzm7dpI94=.sha-256@antelope.email> References: <65CD4EEE481E0F48F4DD6EE5@JcK-HP8200> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 12:43:00 -0000 How about noncommittal wording that leaves the option of using 8bit cte open, suggests doing that for smtputf8 and notes that there may still be software around that has problems with it so perhaps avoid in other cases? No MUST anywhere and it had a touch of realism. Arnt From nobody Wed Aug 10 08:00:00 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17EE12D737 for ; Wed, 10 Aug 2016 07:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 m9D9gyIGlcLj for ; Wed, 10 Aug 2016 07:59:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803C612D5D1 for ; Wed, 10 Aug 2016 07:59:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 62815B80D04; Wed, 10 Aug 2016 07:59:57 -0700 (PDT) To: wmills_92105@yahoo.com, msk@fb.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, superuser@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160810145957.62815B80D04@rfc-editor.org> Date: Wed, 10 Aug 2016 07:59:57 -0700 (PDT) Archived-At: Cc: kandersen@linkedin.com, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC7293 (4771) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 14:59:59 -0000 The following errata report has been submitted for RFC7293, "The Require-Recipient-Valid-Since Header Field and SMTP Service Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7293&eid=4771 -------------------------------------- Type: Technical Reported by: Kurt Andersen Section: 3.2 Original Text ------------- "date-time" is defined in Section 3.3, and "addr-spec" is defined in Section 3.4.1 of [MAIL]. Corrected Text -------------- "date-time" is defined in Section 3.3 of [MAIL], and "addr-spec" is defined in Section 3.4.1 of [MAIL]. Notes ----- https://tools.ietf.org/html/rfc7293#page-6 links the "Section 3.3" reference to https://tools.ietf.org/html/rfc7293#section-3.3 instead of the correct https://tools.ietf.org/html/rfc5322#section-3.3. 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7293 (draft-ietf-appsawg-rrvs-header-field-11) -------------------------------------- Title : The Require-Recipient-Valid-Since Header Field and SMTP Service Extension Publication Date : July 2014 Author(s) : W. Mills, M. Kucherawy Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Aug 10 15:05:37 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445CD12D899 for ; Wed, 10 Aug 2016 15:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.868 X-Spam-Level: X-Spam-Status: No, score=-3.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-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 hTlRZH9GqmbI for ; Wed, 10 Aug 2016 15:05:25 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8307912D891 for ; Wed, 10 Aug 2016 15:05:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1D7491E5A3A; Wed, 10 Aug 2016 15:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa-6R27k7JR0; Wed, 10 Aug 2016 15:01:50 -0700 (PDT) Received: from [192.168.0.5] (cpe-76-174-176-44.socal.res.rr.com [76.174.176.44]) by c8a.amsl.com (Postfix) with ESMTPA id C22FA1E5A35; Wed, 10 Aug 2016 15:01:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20160810145957.62815B80D04@rfc-editor.org> Date: Wed, 10 Aug 2016 15:05:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2094713D-EEC1-45E4-A112-19AEC8DB00C0@amsl.com> References: <20160810145957.62815B80D04@rfc-editor.org> To: RFC System X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ben@nostrum.com, apps-discuss@ietf.org, msk@fb.com, aamelnikov@fastmail.fm, kandersen@linkedin.com, wmills_92105@yahoo.com Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7293 (4771) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 22:05:27 -0000 All, Please note that this errata report has been removed. As stated at=20 http://www.rfc-editor.org/errata.php: "Errata are for the RFCs as available from rfc-editor.org. We have sent separate mail regarding this error to=20 webmaster@tools.ietf.org. Thank you. RFC Editor/mf On Aug 10, 2016, at 7:59 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC7293, > "The Require-Recipient-Valid-Since Header Field and SMTP Service = Extension". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7293&eid=3D4771 >=20 > -------------------------------------- > Type: Technical > Reported by: Kurt Andersen >=20 > Section: 3.2 >=20 > Original Text > ------------- > "date-time" is defined in Section 3.3, and "addr-spec" is=20 > defined in Section 3.4.1 of [MAIL]. >=20 > Corrected Text > -------------- > "date-time" is defined in Section 3.3 of [MAIL], and=20 > "addr-spec" is defined in Section 3.4.1 of [MAIL]. >=20 > Notes > ----- > https://tools.ietf.org/html/rfc7293#page-6 links the "Section 3.3" = reference to https://tools.ietf.org/html/rfc7293#section-3.3 instead of = the correct https://tools.ietf.org/html/rfc5322#section-3.3. >=20 > 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 (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7293 (draft-ietf-appsawg-rrvs-header-field-11) > -------------------------------------- > Title : The Require-Recipient-Valid-Since Header Field = and SMTP Service Extension > Publication Date : July 2014 > Author(s) : W. Mills, M. Kucherawy > Category : PROPOSED STANDARD > Source : Applications Area Working Group APP > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 From nobody Fri Aug 12 06:04:12 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0C12D0C6; Fri, 12 Aug 2016 06:04:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147100705006.12514.10308934145463881472.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2016 06:04:10 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-12.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 13:04:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-12.txt Pages : 36 Date : 2016-08-12 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. This document obsoletes RFC 3798 and updates RFC 2046 and RFC 3461. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 12 08:37:03 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEBC12D13B for ; Fri, 12 Aug 2016 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 mgGiCOuuuKfy for ; Fri, 12 Aug 2016 08:37:01 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9196512D603 for ; Fri, 12 Aug 2016 08:37:00 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1bYEW3-0005Qa-BD; Fri, 12 Aug 2016 11:36:59 -0400 Date: Fri, 12 Aug 2016 11:36:54 -0400 From: John C Klensin To: Alexey Melnikov Message-ID: <54A0127BF1E106F08CE6CF58@JcK-HP8200> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] draft-ietf-appsawg-mdn-3798bis-12 and draft-melnikov-mdn-3798bis-eai-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 15:37:03 -0000 Hi. Ok, I'm confused. Just in case I'm not the only one, I notice that these two drafts have been posted within the last 24 hours and that draft-melnikov-mdn-3798bis-eai-00.txt seems to be identical to draft-ietf-appsawg-mdn-3798bis-12.txt except that the former adds a new Section 3.4 titled "UTF-8 Message Disposition Notifications" which appears to replace most of RFC 6533. Some questions: (1) Is the intent to have draft-melnikov-mdn-3798bis-eai replace draft-ietf-appsawg-mdn-3798bis? If so, why not say so in the drafts and tracker? (2) If the intent is to progress draft-ietf-appsawg-mdn-3798bis to Internet Standard and then use draft-melnikov-mdn-3798bis-eai to "update" it, doesn't that get us tangled up with the forking problems discussed in previous postings? In addition, because, AFAICT, that sequence of actions would result in a Proposed Standard updating or replacing an Internet Standard, doesn't it open that can of worms and the resulting confusion about just what is "the standard"? (3) draft-melnikov-mdn-3798bis-eai indicates that it updates RFC 6533, but contains no indication of just what it updates and what it leaves in place. Some of the material in Section 3.4 seems to make reference to 6533 text, but the relationship is not clear. At least an explanation of what is changed/replaced and what remains seems necessary to proper review and consideration of this document as well as to allowing implementers to figure out what we expect them to do. For all of the reasons in the "fork" thread/discussions, it would be far preferable, IMO, to copy what is needed and simply obsolete 6533. (4) The historical RFC Editor nominal upper limit for an abstract is 13 lines, a limit that (deliberately) approximately the rules in the style guides of other technical publishers. Significantly longer discussions are usually seen as executive summaries, not abstracts, or as very exceptional cases. The abstract in these documents seems to be about 23 lines long (a few less if one does not count the blank lines between paragraphs, one more if "RFC 6533" is added to the last sentence of the one in the "eai" version, which seems necessary for consistency). Can this be trimmed back? Or are there exception circumstances of which I'm not aware? Recommendations: (i) Unless there is a compelling reason for advancing MDNs to Internet Standard now, drop draft-ietf-appsawg-mdn-3798bis and focus on the "eai" specification so that we don't have two documents that apply to the same subject matter and that are nearly identical except in one section in the pipe at the same time. If there is such a compelling reason, it should be made explicit for the community. (ii) Improve the "eai" specification to explain its relationship to 6533, include additional 6533 materials as needed, and obsolete 6533. Once that is done and published, track implementations of that spec closely and move the whole business to Internet Standard as soon as possible (ideally by reclassification rather than yet another document). (iii) If it is not feasible or desired by the community to set draft-ietf-appsawg-mdn-3798bis aside, it should incorporate a clear A/S discussing its applicability relative to 6533 and possible replacements for 6533. Assuming good sense is still a stronger principle in the IETF than the many rules we keep inventing, there should be no problem with either incorporating such a statement and explanation in an Internet Standard or a separate, normatively-reference document. Just my opinion, but I remain concerned about causing confusion about what should be implemented, creating real or apparent forks, and impeding development and deployment of the SMTPUTF8 collection. I don't think reviewing progressing these two, nearly-identical, drafts helps with any of those issues. best, john From nobody Sat Aug 13 17:05:42 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE112B006; Sat, 13 Aug 2016 17:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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=dcrocker.net 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 u6iXbZ7MJUPA; Sat, 13 Aug 2016 17:05:41 -0700 (PDT) Received: from simon.songbird.com (unknown [72.52.113.5]) (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 1963612D17A; Sat, 13 Aug 2016 17:05:41 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u7E05jPg028038 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 13 Aug 2016 17:05:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1471133146; bh=Uu1TBme8v0Inzsc1z39SjOvShspyk/QYSkogU+BP9ew=; h=From:Subject:To:Reply-To:Date:From; b=T2wwAicf4WZU+ogQVy9CICcus8nITC9oCcLSGufio+OWoKX7NEXuH3NFtLLwCb05U N3PeJL7xenhqZzf6WKwLrRmYpbal0IMynFVche8GE4UHuU5dZbxIaX/oHfvgFyZ7v4 fTpyijMmOCp64Pn2R0cBY7L/XiggdklKXgN/+Rwg= From: Dave Crocker Organization: Brandenburg InternetWorking To: draft-ietf-appsawg-file-scheme@ietf.org, art-ads@ietf.org, apps-discuss@ietf.org Message-ID: <80ffb57e-8af1-e3a0-c35c-80666a5143e7@dcrocker.net> Date: Sat, 13 Aug 2016 17:05:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [apps-discuss] Review of: draft-ietf-appsawg-file-scheme-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 00:05:41 -0000 Review: The file URI Scheme ID: draft-ietf-appsawg-file-scheme-11 Review Date: 13 Aug 2016 Reviewer: D. Crocker Summary ------- This is a followup to my Document Shepherd review of the -05 version on 12 April 2016. The document changes are effective. I found only a few places to make a few suggestions, mostly minor.[*] There is one significant concern, in Section 3, which continues from the previous review and I've suggested replacement text and this is the presence of normative language. After resolution of this one concern, the document will be ready for publication. Nice job! d/ > 1.1. Notational Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > Throughout this document the term "local file" is used to describe > files that can be accessed through the local file system API using > only the information included in the file path, not relying on other > information such as network addresses. It is important to note that > a local file may not be physically located on the local machine, for > example if a networked file system is transparently mounted into the > local file system. > > The term "local file URI" is used to describe file URIs which have no > authority component, or where the authority is the special string probably should be: "authority" component, given the surrounding conventions used in this paragraph. > "localhost" or a fully qualified domain name that resolves to the > machine from which the URI is being interpreted (Section 2). > > 2. Syntax ... > file-URI = file-scheme ":" file-hier-part > file-scheme = "file" > > file-hier-part = ( "//" auth-path ) > / local-path > > auth-path = [ file-auth ] path-absolute Hmmm. I wondered how file-auth and path-absolute were separated, but see from Section 3.3 of RFC 3986 that path-absolute beings with a "/". I think this means that if there is no file-auth, the beginning will be "file:///" etc. Is that intended? > > local-path = path-absolute > > file-auth = "localhost" > / host > > The "host" is the fully qualified domain name of the system on which > the file is accessible. This allows a client on another system to > know that it cannot access the file system, or perhaps to use some perhaps to use -> or perhaps that they need to use > other local mecahnism to access the file. ... > > Some file systems have case-sensitive file naming and some do not. > As such the file URI scheme supports case sensitivity, in order to > retain the case as given. Any transport-related handling of the file > URI scheme MUST retain the case as given. Any mapping to or from a > case-insensitive form is soley the responsibility of the soley -> solely > implementation processing the file URI on behalf of the referenced > file system. > > Some file systems allow directory objects to be treated as files in > some cases. This can be reflected in a file URI by omitting the > trailing slash "/" from the path. Be aware that merging a relative oh? I would have thought it would have required retaining a trailing "/" if the URI is for a folder, and dropping it if it refers to a file... > URI reference to such a base URI as per Section 5.2 of [RFC3986] > could remove the directory name from the resulting target URI. ... > 3. Operations Involving file URIs I am going to again raise a concern about this. The document isn't providing enough detail about the processing of URIs to be meaningful, nevermind normative. (I can even argue that the normative directive here is wrong in various write-only cases. One might respond that that's why it's a SHOULD rather than MUST, but my view of SHOULDs is that violating them needs to be exceptional, and activities like write-only sensor networks don't strike me as that special. In other words, I encourage remove all normative language here. I believe the easiest and most reasonable action is to remove the first two sentences, below, and start with "See the". ... > 4. File System Name Encoding > > File systems use various encoding schemes to store file and directory > names. Many modern file systems store file and directory names as > arbitrary sequences of octets, in which case the representation as an > encoded string often depends on the user's localization settings, or > defaults to UTF-8 [STD63]. > > When a file URI is produced, characters not allowed by the syntax in > Section 2 SHOULD be percent-encoded as characters using UTF-8 > encoding, as per [RFC3986], Section 2.5. > > However, encoding information for file and/or directory names might > not be available. In these cases, implementations MAY use heuristics > to determine the encoding. If that fails, they SHOULD percent-encode > the raw bytes of the label directly. An IETF protocol that has normative language allowing heuristics is asking for all sorts of problems. And here I believe it isn't necessary, though I think I understand the difficulty you are trying to deal with. Consider this as a replacement for the above paragraph: A decision not to use percent-encoding is outside the scope of this specification. It will typically require use of heuristics or explicit knowledge about the way the string will be processed. d/ [*] I'll mention that I've just come off of reviewing 3 other documents that I found highly problematic and was probably in an unusually cantankerous mood when reviewing the file scheme revision here. So I actually put some effort into looking for clarity and correctness problems, especially in the core part of the document, Section 2. It was really quite pleasant to /fail/ in that effort. Thanks! -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 14 03:17:07 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3AE128E19; Sun, 14 Aug 2016 03:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UPbVfeDetxRm; Sun, 14 Aug 2016 03:17:01 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 2E8C512D6AA; Sun, 14 Aug 2016 03:17:01 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id c13so8365433ith.1; Sun, 14 Aug 2016 03:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nCka1fAfk9dHuGVt1xf73KXvxFe76MiOK9RGp3r07jM=; b=xTG10K+FKMZJNnB3+yOar01w1DxicNsK2UteDHU0jmDRfxa0wtqbZ9ow7LB9d1h3I3 aaZ7KwpnWTdpnElI4tKJXZ9o68NFpBdx/y+Es5KghZkoBDv2nSIvJ7ZMa3cKFhlXty7V 4Z1cVf6wcNUbjk+AeyP4262iQlZpIa7nT7EHagjhXa0gF5FTv24mLtF6PNCN7HcQnTBd /6m/ee8EsgS0i8JekncV/MWQK6UabhAa9lBzihLCxkXKmdgv1f/oPfmrtWluUicPBntr kP5qiGhTgjuGhMrjlIt0EBXDF1ZDJ4n3PKo7WyUdJ8OX5j1Vxc0q3Fz0UHc+O6NM7gQj I/VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nCka1fAfk9dHuGVt1xf73KXvxFe76MiOK9RGp3r07jM=; b=ckeQbIu+g/mlRUbJaabWUxKXrNr3Px8GT08677SNFpUBEVmq+CpcQASMn57+vhowcB 0+mNeQ9HTFwjfupCaaZb/E06xMwJsehwICwUOln8De4sWOgW8kYHtQNvDUPhF9RJPYu8 efS+jeJRxr/Qh8x1ELecMnxDkJvwEubUyMecU6Unr8U5YDFkj5Zw/fosoF9lDQMBh13p WkOEySnviynDwUuHYxzET/CoLe+L4/Mpm7cxN5aJQHnN2iwzzIfK+cIFy/m9qyh+uVD7 wb80sd8KH726n4Gt1uds6xB+XnDCteOqpxTzaefLHsYLtnK54O7YoDxC85OVbS5P9hf1 x+yg== X-Gm-Message-State: AEkooutLyCI5eMwtkcXylP+V9NVJOv9QkDryxqiMMCwGhEkJOBqgxRIGGDLFT0n1y7iu+ebo49KqRiS19tZQgA== X-Received: by 10.36.94.16 with SMTP id h16mr8067258itb.45.1471169820372; Sun, 14 Aug 2016 03:17:00 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.158.207 with HTTP; Sun, 14 Aug 2016 03:16:59 -0700 (PDT) In-Reply-To: <80ffb57e-8af1-e3a0-c35c-80666a5143e7@dcrocker.net> References: <80ffb57e-8af1-e3a0-c35c-80666a5143e7@dcrocker.net> From: Matthew Kerwin Date: Sun, 14 Aug 2016 20:16:59 +1000 X-Google-Sender-Auth: uJQrOAwUiilNaoEGTSlObbnbSkM Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11424ada8c352f053a056a45 Archived-At: Cc: Mark Nottingham , art-ads@ietf.org, IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-file-scheme-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 10:17:05 -0000 --001a11424ada8c352f053a056a45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 August 2016 at 10:05, Dave Crocker wrote: > > Review: The file URI Scheme > ID: draft-ietf-appsawg-file-scheme-11 > Review Date: 13 Aug 2016 > Reviewer: D. Crocker > > > Summary > ------- > > This is a followup to my Document Shepherd review of the -05 version on 1= 2 > April 2016. > > The document changes are effective. I found only a few places to make a > few suggestions, mostly minor.[*] > > There is one significant concern, in Section 3, which continues from the > previous review and I've suggested replacement text and this is the > presence of normative language. > > After resolution of this one concern, the document will be ready for > publication. > > Nice job! > > d/ > > > > > 1.1. Notational Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119]. >> >> Throughout this document the term "local file" is used to describe >> files that can be accessed through the local file system API using >> only the information included in the file path, not relying on other >> information such as network addresses. It is important to note that >> a local file may not be physically located on the local machine, for >> example if a networked file system is transparently mounted into the >> local file system. >> >> The term "local file URI" is used to describe file URIs which have no >> authority component, or where the authority is the special string >> > > probably should be: "authority" component, given the surrounding > conventions used in this paragraph. > > =E2=80=8BNo worries, will change that.=E2=80=8B > > "localhost" or a fully qualified domain name that resolves to the >> machine from which the URI is being interpreted (Section 2). >> >> 2. Syntax >> > ... > >> file-URI =3D file-scheme ":" file-hier-part >> file-scheme =3D "file" >> >> file-hier-part =3D ( "//" auth-path ) >> / local-path >> >> auth-path =3D [ file-auth ] path-absolute >> > > Hmmm. I wondered how file-auth and path-absolute were separated, but see > from Section 3.3 of RFC 3986 that path-absolute beings with a "/". > > I think this means that if there is no file-auth, the beginning will be > "file:///" etc. Is that intended? > > =E2=80=8BYes; RFC1738 file URIs look like "file:///foo/bar" (meaning file "= bar" in directory "/foo"). > >> local-path =3D path-absolute >> >> file-auth =3D "localhost" >> / host >> >> The "host" is the fully qualified domain name of the system on which >> the file is accessible. This allows a client on another system to >> know that it cannot access the file system, or perhaps to use some >> > > perhaps to use -> or perhaps that they need to use > > =E2=80=8BACK=E2=80=8B > > other local mecahnism to access the file. >> > ... > =E2=80=8BHeh, "mecahnism" is a typo too.=E2=80=8B > >> Some file systems have case-sensitive file naming and some do not. >> As such the file URI scheme supports case sensitivity, in order to >> retain the case as given. Any transport-related handling of the file >> URI scheme MUST retain the case as given. Any mapping to or from a >> case-insensitive form is soley the responsibility of the >> > > soley -> solely > > =E2=80=8BACK=E2=80=8B > > implementation processing the file URI on behalf of the referenced >> file system. >> >> Some file systems allow directory objects to be treated as files in >> some cases. This can be reflected in a file URI by omitting the >> trailing slash "/" from the path. Be aware that merging a relative >> > > oh? I would have thought it would have required retaining a trailing "/" > if the URI is for a folder, and dropping it if it refers to a file... > > =E2=80=8BUnless you're intentionally treating the directory as a file. In t= he UNIX path "/foo/bar", 'bar' might be a directory, even without a trailing "/"; and if you used that path to create a file URI like "file:///foo/bar" you need to be careful with relative references. I think I will just delete the paragraph; it doesn't add much (except for confusion.) It's certainly not worth a couple of round-trips to refine.=E2= =80=8B > > URI reference to such a base URI as per Section 5.2 of [RFC3986] >> could remove the directory name from the resulting target URI. >> > ... > > 3. Operations Involving file URIs >> > > I am going to again raise a concern about this. The document isn't > providing enough detail about the processing of URIs to be meaningful, > nevermind normative. (I can even argue that the normative directive here > is wrong in various write-only cases. One might respond that that's why > it's a SHOULD rather than MUST, but my view of SHOULDs is that violating > them needs to be exceptional, and activities like write-only sensor > networks don't strike me as that special. > > In other words, I encourage remove all normative language here. I believ= e > the easiest and most reasonable action is to remove the first two > sentences, below, and start with "See the". > > =E2=80=8BThat works for me.=E2=80=8B > > ... > > 4. File System Name Encoding >> >> File systems use various encoding schemes to store file and directory >> names. Many modern file systems store file and directory names as >> arbitrary sequences of octets, in which case the representation as an >> encoded string often depends on the user's localization settings, or >> defaults to UTF-8 [STD63]. >> >> When a file URI is produced, characters not allowed by the syntax in >> Section 2 SHOULD be percent-encoded as characters using UTF-8 >> encoding, as per [RFC3986], Section 2.5. >> >> However, encoding information for file and/or directory names might >> not be available. In these cases, implementations MAY use heuristics >> to determine the encoding. If that fails, they SHOULD percent-encode >> the raw bytes of the label directly. >> > > An IETF protocol that has normative language allowing heuristics is askin= g > for all sorts of problems. And here I believe it isn't necessary, though= I > think I understand the difficulty you are trying to deal with. > > Consider this as a replacement for the above paragraph: > > A decision not to use percent-encoding is outside the scope of this > specification. It will typically require use of heuristics or explicit > knowledge about the way the string will be processed. > > =E2=80=8BI'm happy with that, but I'll say "...not to use percent-encoded UTF-8...".=E2=80=8B > > > d/ > > [*] I'll mention that I've just come off of reviewing 3 other documents > that I found highly problematic and was probably in an unusually > cantankerous mood when reviewing the file scheme revision here. So I > actually put some effort into looking for clarity and correctness problem= s, > especially in the core part of the document, Section 2. It was really > quite pleasant to /fail/ in that effort. Thanks! > > =E2=80=8BI appreciate the effort, and the outcome. Thank you too. I'll sub= mit this version (-12) right now.=E2=80=8B > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > =E2=80=8BCheers=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11424ada8c352f053a056a45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 14 August 2016 at 10:05, Dave Crocker <dhc2@dcrocker= .net> wrote:

Review:=C2=A0 =C2=A0The file URI Scheme
ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-appsawg-file-scheme-11
Review Date:=C2=A0 13 Aug 2016
Reviewer:=C2=A0 =C2=A0 =C2=A0D. Crocker <dcrocker@bbiw.net>


Summary
-------

This is a followup to my Document Shepherd review of the -05 version on 12 = April 2016.

The document changes are effective.=C2=A0 I found only a few places to make= a few suggestions, mostly minor.[*]

There is one significant concern, in Section 3, which continues from the pr= evious review and I've suggested replacement text and this is the prese= nce of normative language.

After resolution of this one concern, the document will be ready for public= ation.

Nice job!

d/




1.1.=C2=A0 Notational Conventions

=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "MAY", and "OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as described in [RFC2119].

=C2=A0 =C2=A0Throughout this document the term "local file" is us= ed to describe
=C2=A0 =C2=A0files that can be accessed through the local file system API u= sing
=C2=A0 =C2=A0only the information included in the file path, not relying on= other
=C2=A0 =C2=A0information such as network addresses.=C2=A0 It is important t= o note that
=C2=A0 =C2=A0a local file may not be physically located on the local machin= e, for
=C2=A0 =C2=A0example if a networked file system is transparently mounted in= to the
=C2=A0 =C2=A0local file system.

=C2=A0 =C2=A0The term "local file URI" is used to describe file U= RIs which have no
=C2=A0 =C2=A0authority component, or where the authority is the special str= ing

probably should be: "authority" component, given the surrounding = conventions used in this paragraph.


=E2=80=8BNo worries, will cha= nge that.=E2=80=8B

=C2=A0

=C2=A0 =C2=A0"localhost" or a fully qualified domain name that re= solves to the
=C2=A0 =C2=A0machine from which the URI is being interpreted (Section 2).
2.=C2=A0 Syntax
...
=C2=A0 =C2=A0 =C2=A0 file-URI=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D file-scheme &qu= ot;:" file-hier-part
=C2=A0 =C2=A0 =C2=A0 file-scheme=C2=A0 =C2=A0 =3D "file"

=C2=A0 =C2=A0 =C2=A0 file-hier-part =3D ( "//" auth-path )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/ local-path

=C2=A0 =C2=A0 =C2=A0 auth-path=C2=A0 =C2=A0 =C2=A0 =3D [ file-auth ] path-a= bsolute

Hmmm.=C2=A0 I wondered how file-auth and path-absolute were separated, but = see from Section 3.3 of RFC 3986 that path-absolute beings with a "/&q= uot;.

I think this means that if there is no file-auth, the beginning will be &qu= ot;file:///" etc.=C2=A0 Is that intended?


=E2=80=8BYes;= RFC1738 file URIs look like "file:///foo/bar" (mean= ing file "bar" in directory "/foo").

=C2=A0

=C2=A0 =C2=A0 =C2=A0 local-path=C2=A0 =C2=A0 =C2=A0=3D path-absolute

=C2=A0 =C2=A0 =C2=A0 file-auth=C2=A0 =C2=A0 =C2=A0 =3D "localhost"= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/ host

=C2=A0 =C2=A0The "host" is the fully qualified domain name of the= system on which
=C2=A0 =C2=A0the file is accessible.=C2=A0 This allows a client on another = system to
=C2=A0 =C2=A0know that it cannot access the file system, or perhaps to use = some

=C2=A0 perhaps to use -> or perhaps that they need to use


=E2=80=8BACK=E2=80=8B
=C2=A0

=C2=A0 =C2=A0other local mecahnism to access the file.
...

=E2=80=8BHeh, "mecah= nism" is a typo too.=E2=80=8B

=C2=A0

=C2=A0 =C2=A0Some file systems have case-sensitive file naming and some do = not.
=C2=A0 =C2=A0As such the file URI scheme supports case sensitivity, in orde= r to
=C2=A0 =C2=A0retain the case as given.=C2=A0 Any transport-related handling= of the file
=C2=A0 =C2=A0URI scheme MUST retain the case as given.=C2=A0 Any mapping to= or from a
=C2=A0 =C2=A0case-insensitive form is soley the responsibility of the

=C2=A0soley -> solely


=E2=80=8BACK=E2=80=8B
=C2=A0

=C2=A0 =C2=A0implementation processing the file URI on behalf of the refere= nced
=C2=A0 =C2=A0file system.

=C2=A0 =C2=A0Some file systems allow directory objects to be treated as fil= es in
=C2=A0 =C2=A0some cases.=C2=A0 This can be reflected in a file URI by omitt= ing the
=C2=A0 =C2=A0trailing slash "/" from the path.=C2=A0 Be aware tha= t merging a relative

oh?=C2=A0 I would have thought it would have required retaining a trailing = "/" if the URI is for a folder, and dropping it if it refers to a= file...


=E2=80=8BUnle= ss you're intentionally treating the directory as a file. In the UNIX p= ath "/foo/bar", 'bar' might be a= directory, even without a trailing "/"; and if you used that pat= h to create a file URI like "file:///foo/bar" you ne= ed to be careful with relative references.

<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">I think I will just delete the paragraph; it doesn't add much (= except for confusion.) It's certainly not worth a couple of round-trips= to refine.=E2=80=8B

=C2=A0

=C2=A0 =C2=A0URI reference to such a base URI as per Section 5.2 of [RFC398= 6]
=C2=A0 =C2=A0could remove the directory name from the resulting target URI.=
...

3.=C2=A0 Operations Involving file URIs

I am going to again raise a concern about this.=C2=A0 The document isn'= t providing enough detail about the processing of URIs to be meaningful, ne= vermind normative.=C2=A0 (I can even argue that the normative directive her= e is wrong in various write-only cases.=C2=A0 One might respond that that&#= 39;s why it's a SHOULD rather than MUST, but my view of SHOULDs is that= violating them needs to be exceptional, and activities like write-only sen= sor networks don't strike me as that special.

In other words, I encourage remove all normative language here.=C2=A0 I bel= ieve the easiest and most reasonable action is to remove the first two sent= ences, below, and start with "See the".


=E2=80=8BThat works for me.= =E2=80=8B

=C2=A0

...

4.=C2=A0 File System Name Encoding

=C2=A0 =C2=A0File systems use various encoding schemes to store file and di= rectory
=C2=A0 =C2=A0names.=C2=A0 Many modern file systems store file and directory= names as
=C2=A0 =C2=A0arbitrary sequences of octets, in which case the representatio= n as an
=C2=A0 =C2=A0encoded string often depends on the user's localization se= ttings, or
=C2=A0 =C2=A0defaults to UTF-8 [STD63].

=C2=A0 =C2=A0When a file URI is produced, characters not allowed by the syn= tax in
=C2=A0 =C2=A0Section 2 SHOULD be percent-encoded as characters using UTF-8<= br> =C2=A0 =C2=A0encoding, as per [RFC3986], Section 2.5.

=C2=A0 =C2=A0However, encoding information for file and/or directory names = might
=C2=A0 =C2=A0not be available.=C2=A0 In these cases, implementations MAY us= e heuristics
=C2=A0 =C2=A0to determine the encoding.=C2=A0 If that fails, they SHOULD pe= rcent-encode
=C2=A0 =C2=A0the raw bytes of the label directly.

An IETF protocol that has normative language allowing heuristics is asking = for all sorts of problems.=C2=A0 And here I believe it isn't necessary,= though I think I understand the difficulty you are trying to deal with.
Consider this as a replacement for the above paragraph:

=C2=A0 =C2=A0 =C2=A0A decision not to use percent-encoding is outside the s= cope of this specification.=C2=A0 It will typically require use of heuristi= cs or explicit knowledge about the way the string will be processed.


=E2=80=8BI'm happy with t= hat, but I'll say "...not to use percent-encoded UTF-8...".= =E2=80=8B

=C2=A0


d/

[*] I'll mention that I've just come off of reviewing 3 other docum= ents that I found highly problematic and was probably in an unusually canta= nkerous mood when reviewing the file scheme revision here.=C2=A0 So I actua= lly put some effort into looking for clarity and correctness problems, espe= cially in the core part of the document, Section 2.=C2=A0 It was really qui= te pleasant to /fail/ in that effort.=C2=A0 Thanks!


=E2=80=8BI appr= eciate the effort, and the outcome. Thank you too.=C2=A0 I'll submit th= is version (-12) right now.=E2=80=8B

=C2=A0

=C2=A0 Dave Crocker
=C2=A0 Brandenburg InternetWorking
=C2=A0 bbi= w.net


=E2=80=8BCheers=E2=80=8B
--
=C2=A0 Matthew Kerwin
= =C2=A0 http://m= atthew.kerwin.net.au/
--001a11424ada8c352f053a056a45-- From nobody Sun Aug 14 03:22:50 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B1412D140; Sun, 14 Aug 2016 03:22:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147117016586.13899.16470286674831887334.idtracker@ietfa.amsl.com> Date: Sun, 14 Aug 2016 03:22:45 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-12.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 10:22:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-12.txt Pages : 18 Date : 2016-08-14 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, replacing the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 14 07:05:46 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB212D669; Sun, 14 Aug 2016 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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=dcrocker.net 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 SIxemOMsc2Eg; Sun, 14 Aug 2016 07:05:44 -0700 (PDT) Received: from simon.songbird.com (unknown [72.52.113.5]) (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 3213512D63C; Sun, 14 Aug 2016 07:05:44 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u7EE5mNL029463 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 14 Aug 2016 07:05:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1471183549; bh=3WLuRBPvUIGMcx4yhb3UAUL/EacdjrTAWc8lbxd/W1c=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=AV/7jmWxi9NynKHkfbZ5TNCWNyuMIdzEDzgWSY7OuXULDpgpBWw2VP9JA0TxKa3kh doTUv3S7k7n1uDaKDxSphUVIclp6asOMMxwDVOTZH3PQaUedvesmjD4ZI9qlc40RNP rpP3NwOcyjiaa6RGP3amHjiFPKnihDG7r+et9gK0= To: Matthew Kerwin References: <80ffb57e-8af1-e3a0-c35c-80666a5143e7@dcrocker.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <14a094be-0b7f-a0ab-0bd8-0c9c8fed54e9@dcrocker.net> Date: Sun, 14 Aug 2016 07:05:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Mark Nottingham , draft-ietf-appsawg-file-scheme@ietf.org, art-ads@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-file-scheme-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 14:05:44 -0000 On 8/14/2016 3:16 AM, Matthew Kerwin wrote: > I'll submit this version (-12) right now.​ Indeed you did. And I've just submitted the Shepherd's report to initiate the IESG process. Again, nice job. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 14 11:10:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFBD12D78C; Sun, 14 Aug 2016 11:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WsIRc2ryyY_j; Sun, 14 Aug 2016 11:10:07 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 2B4E312D0A6; Sun, 14 Aug 2016 11:10:07 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id j12so17187527ywb.2; Sun, 14 Aug 2016 11:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=VwplfsbZ1/1viGoBxtj6FVztmftZdTW0var1tFYMIEw=; b=tLs7JauOedYXfAR28y4zvVMTGcNmZ3z8wIzNCHxYqUMxG1DQJNtZVZNyvc5JWiDtCh 4UOgj+isF0f2S2ZJ2PezTnWrf2iL8oCOv+qvlNjfrU/4PPjna9tGh9EUJ9t0ejuKW787 1vDpRf5/HRurEEDWkxm/h/SSf3fbHo9YATwzfuHwiB4Suk88n3xMOZeFOIeD6BaMLlKN C6KwvvQWJdtDKp7aRfz7X4p4iJh6TClSCk8e1X/eBYQL2ghiX8nSwettcWEIlC4FzoAT TYkHe3SJAcLGgyTqJ4KIxGb5pQnb8icvmGICg2l4KqzhKufxKtRG+ICJMJSZaolezlEN GTkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VwplfsbZ1/1viGoBxtj6FVztmftZdTW0var1tFYMIEw=; b=beTzOtMiGhk5+D4VaWa51C14bTyRZTsdWkSfK/Oa76YIGti8+yA9zGZIrg9vEbBus3 ekByoQYgQwRWG2XFAvo9otYf96ylMOvEbt+Um3iT83A7XsisUIvvz5dZxUWs/xphWYV6 yK6WjmVtqzq2peJ0dtGXQq+gNc6s6A/x/tm9z/DV6gRfEeSeQlvGKFIuKsCpO1svA+6W AmFR6d9LGjiGJnE67NKrLrToi+VGYl7P2P9YPscLlHUoUQAhrvRypqoWo50VqmX9rCLO ndioKxL5WALBQZ+O1txN7LhRcGLwJpDvzYENH8WcM5WLvsMCe2QlXfwanPDuy/GTaOOX MvUg== X-Gm-Message-State: AEkoouvGHVt2RNFnFMmCu9cc6jqw5w3lP8pfyyNkm/rOamxOfbAL34HLH8U4giylieMRtznWyv8CpddvHsD98w== X-Received: by 10.13.230.2 with SMTP id p2mr17667859ywe.125.1471198206416; Sun, 14 Aug 2016 11:10:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.84 with HTTP; Sun, 14 Aug 2016 11:10:05 -0700 (PDT) From: "Murray S. Kucherawy" Date: Sun, 14 Aug 2016 11:10:05 -0700 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=94eb2c0878d67cfcd1053a0c0615 Archived-At: Cc: IETF Apps Discuss , ART ADs , Mark Nottingham , draft-ietf-appsawg-file-scheme@ietf.org Subject: [apps-discuss] Second Working Group Last Call: draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 18:10:09 -0000 --94eb2c0878d67cfcd1053a0c0615 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 14, 2016 at 7:05 AM, Dave Crocker wrote: > On 8/14/2016 3:16 AM, Matthew Kerwin wrote: > >> I'll submit this version (-12) right now.=E2=80=8B >> > > Indeed you did. And I've just submitted the Shepherd's report to initiat= e > the IESG process. > > Again, nice job. > > Thanks everyone for the push to get this ready. Given past discussions with the document shepherd and the fact that the document has been updated eight times since the original WGLC, I believe it's prudent to do one more. Accordingly, this note initiates a second WGLC for draft-ietf-appsawg-file-scheme, ending 8/26. Please review the document and submit review comments to this list, to me directly, or to the shepherd directly, by then. Although substantive comments are preferable, acknowledgement that the draft has been reviewed would be helpful. -MSK, APPSAWG co-chair --94eb2c0878d67cfcd1053a0c0615 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 14, 2016 at 7:05 AM, Dave Crocker <dhc2@dcroc= ker.net> wrote:
On 8/14/2016 3:= 16 AM, Matthew Kerwin wrote:
I'll submit this version (-12) right now.=E2=80=8B

 Indeed you did.=C2=A0 And I've just submitted the Shepherd's report= to initiate the IESG process.

Again, nice job.


Thanks everyone for the = push to get this ready.

Given past discussions with the d= ocument shepherd and the fact that the document has been updated eight time= s since the original WGLC, I believe it's prudent to do one more.=C2=A0= Accordingly, this note initiates a second WGLC for draft-ietf-appsawg-file= -scheme, ending 8/26.=C2=A0 Please review the document and submit review co= mments to this list, to me directly, or to the shepherd directly, by then.= =C2=A0 Although substantive comments are preferable, acknowledgement that t= he draft has been reviewed would be helpful.

-MSK, APPSAW= G co-chair

--94eb2c0878d67cfcd1053a0c0615-- From nobody Mon Aug 22 20:59:41 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA912D85C; Mon, 22 Aug 2016 20:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=n58A6jMP; dkim=pass (1024-bit key) header.d=emc.com header.b=k+yNBqXx 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 H5gC4wl_SGYW; Mon, 22 Aug 2016 20:59:32 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 A8E5912D7FF; Mon, 22 Aug 2016 20:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1471924772; x=1503460772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L5HnpjHfJJPjL9PnlqJz00gASoCoCuptAGSfRbGJ9lA=; b=n58A6jMPHUQ9dOdKzzfswZNqZW4Oec3DAnCdDBu/NuK4RFTC2Sd6monX b2Fki0VArnz23KJgpmVVBIvW3LmIAnSiZAzUZCI/31bBWyTdIgewp7HCC CKPB+7VmauHE4YqlNdEqGte3ZcbcZhp2Dd76A+n5SWr54JBVH95zLE/hl g=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 22:59:32 -0500 Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2016 09:59:30 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7N3xSX6022680 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Aug 2016 23:59:29 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u7N3xSX6022680 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1471924769; bh=dL8dX1UXYRhwf/A2LQzif9xKgSY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=k+yNBqXxHvHrF+zpLM0etCSgX8S2fl2JIKJgIzCyj4Z9pDTLAiMGeblRTZDJrSBWe V+IT16ps2QAirOxPVLoyEj3sU5iEEzEWTANq6w6IjSZkhwy2Bb4NSZSg2xL1ukplIb hMqjQIl4ZUo3gfPE7uHZKqTtnlVCmlerGrChXm3Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u7N3xSX6022680 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 22 Aug 2016 23:59:05 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7N3xA59021587 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 22 Aug 2016 23:59:11 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0266.001; Mon, 22 Aug 2016 23:59:10 -0400 From: "Black, David" To: S Moonesamy , "apps-discuss@ietf.org" , Lars Eggert , Godred Fairhurst , Greg Shepherd Thread-Topic: [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16 Thread-Index: AQHR7zxJfVZEuBWmF02p/XQC8WgdsqBWBgow Date: Tue, 23 Aug 2016 03:59:09 +0000 Message-ID: References: <6.2.5.6.2.20160805084142.0bd419e8@elandnews.com> In-Reply-To: <6.2.5.6.2.20160805084142.0bd419e8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.97.6.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "iesg@ietf.org" , "tsvwg@ietf.org" Subject: Re: [apps-discuss] [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 03:59:34 -0000 > In Section 3.1.9: >=20 > "Applications intended for the Internet SHOULD NOT assume that > QoS mechanisms are supported by the networks they use, and > therefore need to provide congestion control, error recovery, > etc. in case the actual network path does not provide > provisioned service." > > Is there a case when an application intended for use on the Internet > can assume that QoS mechanisms are supported throughout both ends of > the connection? I guess that begs the definition of "intended for the Internet" - if such a= n application has complete knowledge of the network path or paths involved it could know that there is provisioned QoS. That's a specialized case, bu= t it is possible. Thanks, --David (as draft shepherd). > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of S Moonesamy > Sent: Friday, August 05, 2016 12:50 PM > To: apps-discuss@ietf.org; Lars Eggert; Godred Fairhurst; Greg Shepherd > Cc: iesg@ietf.org; tsvwg@ietf.org > Subject: [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16 >=20 > I have been selected as the Applications Area Directorate reviewer > for this draft (for background on APPSDIR, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document > shepherd or AD before posting a new version of the draft. >=20 > Document: draft-ietf-tsvwg-rfc5405bis-16 > Title: UDP Usage Guidelines > Reviewer: S. Moonesamy > Review Date: August 5, 2016 > IETF Last Call Date: May 17, 2016 >=20 > Summary: This draft is almost ready for publication as an Best Common > Practice RFC. >=20 > The document is applicable to application protocol designers instead > of application developers as the recommendation about UDP would have > to be part of the application protocol for ease of implementation. >=20 > Major issues: None >=20 >=20 > Minor issues: >=20 > In Section 3.1.9: >=20 > "Applications intended for the Internet SHOULD NOT assume that > QoS mechanisms are supported by the networks they use, and > therefore need to provide congestion control, error recovery, > etc. in case the actual network path does not provide > provisioned service." >=20 > Is there a case when an application intended for use on the Internet > can assume that QoS mechanisms are supported throughout both ends of > the connection? >=20 > Nits: >=20 > In Section 1: >=20 > "In such cases, it is RECOMMENDED that application designers cite > the respective section(s) of this document in the technical > specification of their application or protocol and explain > their rationale for their design choice.' >=20 > The RFC 2119 key word is used before its definition in Section 2. >=20 > Regards, > S. Moonesamy From nobody Mon Aug 22 22:52:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C5C12D0CE; Mon, 22 Aug 2016 22:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=tVA0KFos; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=t+c6oPrc 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 VY5-iHnUGpQW; Mon, 22 Aug 2016 22:52:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9281C12D0B7; Mon, 22 Aug 2016 22:52:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.227.82.174]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u7N5pXIh015289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2016 22:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1471931507; x=1472017907; bh=U8LMB3hdR9J9QcH2Qj1fayOxJ7wVeKcZhnxaW3LlnJY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tVA0KFosz+eh3WdGneUYZt6gM9H4vRv+st3EVDIr42ldimLHKsDg4pkzikHkByVdQ scAG2BnedYleUPhMKOyJyYtD1BrQv1oWdaco3wB3+5CRYPG7Mqjuv4F6e4IfX7tBKq R2bZdl2YcLf4psKAvLjSF+b5v6xEemF+PjDgKW+w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1471931507; x=1472017907; i=@elandsys.com; bh=U8LMB3hdR9J9QcH2Qj1fayOxJ7wVeKcZhnxaW3LlnJY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=t+c6oPrcuB3MvGSByExbrjC6ZgHa/IOu+vSnPc5Q9quwMLpBNw7sa6WM2fB+y2ns5 qRIZ7v2fschLvgieOmwMnKWHJQPHlLGv7U6GTOW+1SrS3c7+O55k9Zv/f15ovO44nZ F5lVwZzWSPAzA74jF9R+BaZloWJ1lTkh0T5GsDRM= Message-Id: <6.2.5.6.2.20160822210805.0a0616e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 22 Aug 2016 21:11:16 -0700 To: "Black, David" , apps-discuss@ietf.org, Lars Eggert , Godred Fairhurst , Greg Shepherd From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20160805084142.0bd419e8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: iesg@ietf.org Subject: Re: [apps-discuss] [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 05:52:04 -0000 Hi David, At 20:59 22-08-2016, Black, David wrote: >I guess that begs the definition of "intended for the Internet" - if such an >application has complete knowledge of the network path or paths involved >it could know that there is provisioned QoS. That's a specialized case, but >it is possible. Thanks for responding to the review. I consider the review as addressed. Regards, S. Moonesamy From nobody Thu Aug 25 05:45:01 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF5212D0E7; Thu, 25 Aug 2016 05:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 DjNe_eIw4Qaa; Thu, 25 Aug 2016 05:44:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6428F12B010; Thu, 25 Aug 2016 05:44:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5483BB80B46; Thu, 25 Aug 2016 05:44:57 -0700 (PDT) To: vesely@tana.it, superuser@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160825124457.5483BB80B46@rfc-editor.org> Date: Thu, 25 Aug 2016 05:44:57 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, apps-discuss@ietf.org, aamelnikov@fastmail.fm Subject: [apps-discuss] [Errata Verified] RFC7601 (4671) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 12:44:59 -0000 The following errata report has been verified for RFC7601, "Message Header Field for Indicating Message Authentication Status". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7601&eid=4671 -------------------------------------- Status: Verified Type: Editorial Reported by: Ale Date Reported: 2016-04-18 Verified by: Alexey Melnikov (IESG) Section: 2.3 Original Text ------------- The "ptype" in the ABNF above indicates the general type of property being described by the result being reported, upon which the reported ^^^^^ result was based. Coupled with the "property", which is more specific, they indicate from which particular part of the message the reported data were extracted. ^^^^ Corrected Text -------------- The "ptype" in the ABNF above indicates the general type of property being described by the value being reported, upon which the reported ^^^^^ result was based. Coupled with the "property", which is more specific, they indicate from which particular part of the message the reported "pvalue"s were extracted. ^^^^^^^^ Notes ----- The original text can be understood in multiple ways, depending on the meaning attributed to the term "result". The corrected text I submit is one of the possible interpretations. Note that if the first appearance of the term is assumed to be the ABNF "result", then ptype becomes an attribute of method, thereby setting a limit of one ptype per resinfo, as coincidentally it actually is. -------------------------------------- RFC7601 (draft-ietf-appsawg-rfc7001bis-11) -------------------------------------- Title : Message Header Field for Indicating Message Authentication Status Publication Date : August 2015 Author(s) : M. Kucherawy Category : PROPOSED STANDARD Source : ART Area General Application Working Group Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Thu Aug 25 11:29:37 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26FC12D56F for ; Thu, 25 Aug 2016 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 NwZWjUvGGEjq for ; Thu, 25 Aug 2016 11:29:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8219912D568 for ; Thu, 25 Aug 2016 11:29:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6AC17B80E5D; Thu, 25 Aug 2016 11:29:34 -0700 (PDT) To: pbryan@anode.ca, mnot@mnot.net, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, superuser@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160825182934.6AC17B80E5D@rfc-editor.org> Date: Thu, 25 Aug 2016 11:29:34 -0700 (PDT) Archived-At: Cc: d.frey@gmx.de, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC6902 (4787) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 18:29:36 -0000 The following errata report has been submitted for RFC6902, "JavaScript Object Notation (JSON) Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6902&eid=4787 -------------------------------------- Type: Technical Reported by: Daniel Frey Section: 4.2 Original Text ------------- The "remove" operation removes the value at the target location. The target location MUST exist for the operation to be successful. For example: { "op": "remove", "path": "/a/b/c" } If removing an element from an array, any elements above the specified index are shifted one position to the left. Corrected Text -------------- The "remove" operation removes the value at the target location. The target location MUST exist for the operation to be successful. For example: { "op": "remove", "path": "/a/b/c" } If removing an element from an array, any elements above the specified index are shifted one position to the left. The target location MUST NOT be a reference to the root. It is an error in this document: { "op": "remove", "path": "" } Notes ----- The semantics of { "op": "remove", "path": "" } are never specified. If we allow to remove the root element, what would the result be? It would no longer be a valid JSON document, hence I propose to explicitly require the path of the "remove" operation to not reference the root. 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6902 (draft-ietf-appsawg-json-patch-10) -------------------------------------- Title : JavaScript Object Notation (JSON) Patch Publication Date : April 2013 Author(s) : P. Bryan, Ed., M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From luigipinca@libero.it Sun Aug 28 12:50:09 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0BB12D0BF for ; Sun, 28 Aug 2016 12:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=libero.it 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 5gg3HHuTdNkY for ; Sun, 28 Aug 2016 12:50:08 -0700 (PDT) Received: from libero.it (smtp-17.italiaonline.it [212.48.25.145]) (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 1D7EA12D0B9 for ; Sun, 28 Aug 2016 12:50:07 -0700 (PDT) Received: from webmail-56.iol.local ([10.255.25.82]) by smtp-17.iol.local with SMTP id e65ib7s86681se65ibM1g4; Sun, 28 Aug 2016 21:50:04 +0200 x-libjamoibt: 1601 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libero.it; s=s2014; t=1472413804; bh=0uv/QxbxP2DwlPrfWbJudcrxeIHgzc27+A+2cKOlpjQ=; h=Date:From:Reply-To:To:Subject; b=t4rqvr9q4O8r68ONeFMAj+jj/lSpHkj8k7F9glRMrrXfql2pskB1VSXIRLtEJMczp se/pmEjX4Ap2fddEike8FRkxLtQXzIhGqaLDGVC3JVIAy6oDSuYXLu6ZRc6EY3vtrc 0yJu4XVH3lDTH9AmwLoS6exO9w0A3XYyXACACO71+Y/28/y1hKq00xUpEwFfZFpCYb G3o21w1XJBHA8K0Weq8PiRa+U8oA7VCCz6173nsDbzefDThYUGbu/yXvDsi1dkq4fC Ldr+1Lr0xubq5mQ/cD0tBiiLF94MJqmqKlFHIq4lGuhJ5RFsZ2F7uKErQHvAVR4iZI leQfrJ3qoRCEg== X-CNFS-Analysis: v=2.2 cv=LYJ+0XXi c=1 sm=1 tr=0 a=I52joOGmR5L7+fovlJZwvw==:117 a=8D6cX0wMWuUA:10 a=Pfsz1xswR3AA:10 a=x1-6zHxI9d0A:10 a=lVOGhCD4rhh26ZCd9gMA:9 a=QEXdDO2ut3YA:10 a=LPZK7dhTGsBBbkBzCOwA:9 a=hTsGOhNDyr3sUnsx:21 Message-ID: <2119936850.4077721472413802214.JavaMail.httpd@webmail-56.iol.local> Date: Sun, 28 Aug 2016 21:50:02 +0200 (CEST) From: "luigipinca@libero.it" To: apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_467635_1541709415.1472413802213" X-SenderIP: 212.124.190.235 X-libjamv: 8K7rGF1D6ps= X-libjamsun: 2whkkypcNv/zAaENk02754RXGVm5ZhgE X-CMAE-Envelope: MS4wfERbc739o3Kmtbcpz1/MKn1AKyct1WjqoGJeVuHjRdz4B9BKKXcjrk/yPSXo3tRwjh803kKOyYM/27Dezg1NHZxFRV/GYSIgMAW77mOJ+Qc+PWPJKGu+ UfhNiCBJFTfYenJA4CiOSRa2phGEc5eOO9vt3K4MqkYNFDIu6K784v4zGme0PG+bH/FaTvjrX6K8Ag== Archived-At: Subject: [apps-discuss] Question about RFC 7239 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "luigipinca@libero.it" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 19:56:35 -0000 ------=_Part_467635_1541709415.1472413802213 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I have a question about the "Forwarded" HTTP header field, defined in section 4 of RFC 7239. The ABNF definition for the header field value is: Forwarded = 1#forwarded-element forwarded-element = [ forwarded-pair ] *( ";" [ forwarded-pair ] ) forwarded-pair = token "=" value value = token / quoted-string token = quoted-string = If I'm reading this correctly, an empty forwarded-element or one made of only ";" is a valid element. For example these values: Forwarded: ; Forwarded: ,; Forwarded: ;,, are all valid. Why is an empty forwarded-element allowed? Wouldn't it be better to use an ABNF definition like this? Forwarded = forwarded-element *( "," forwarded-element ) forwarded-element = forwarded-pair *( ";" forwarded-pair ) forwarded-pair = token "=" value value = token / quoted-string token = quoted-string = Thank you. Regards, Luigi ------=_Part_467635_1541709415.1472413802213 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello,
I have a question about the "Forwarded" HTTP header field, define= d in section 4 of RFC 7239.
The ABNF definition for the header field val= ue is:

Forwarded=    =3D 1#forwarded-element

forwarded-element =3D
 =   [ forwarded-pair ] *( ";" [ forwarded-pair ] )

forwarded-pair= =3D token "=3D" value
value       &n= bsp;  =3D token / quoted-string

token =3D <Defined in [RFC72= 30], Section 3.2.6>
quoted-string =3D <Defined in [RFC7230], Secti= on 3.2.6>

If I'm reading this correctly, an empty forwarde= d-element or one made of only ";"  is a valid element.
For example = these values:

Fo= rwarded: ;
Forwarded: ,;
Forwarded: ;,,

are = all valid.

Why is an = empty forwarded-element allowed? Wouldn't it be better to use an ABNF definition like this?=

Forwarded =3D
   f= orwarded-element *( "," forwarded-element )

forwarded-element =3D<= br>   forwarded-pair *( ";" forwarded-pair )

forwarded-pai= r =3D token "=3D" value
value       &= nbsp;  =3D token / quoted-string

token =3D <Defined in [RFC7= 230], Section 3.2.6>
quoted-string =3D <Defined in [RFC7230], Sect= ion 3.2.6>

Thank you.

Rega= rds,

Luigi
 ------=_Part_467635_1541709415.1472413802213-- From nobody Sun Aug 28 13:27:57 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF3412B047 for ; Sun, 28 Aug 2016 13:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 jqC6YqCJOoRU for ; Sun, 28 Aug 2016 13:27:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FCF12B03A for ; Sun, 28 Aug 2016 13:27:53 -0700 (PDT) Received: from [192.168.178.20] ([93.217.65.49]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LcVOE-1bERBA1dfa-00jqew; Sun, 28 Aug 2016 22:27:50 +0200 To: "luigipinca@libero.it" , apps-discuss@ietf.org References: <2119936850.4077721472413802214.JavaMail.httpd@webmail-56.iol.local> From: Julian Reschke Message-ID: <8c1cbfee-e459-59c5-0aab-f8d9e54fbd76@gmx.de> Date: Sun, 28 Aug 2016 22:27:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2119936850.4077721472413802214.JavaMail.httpd@webmail-56.iol.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:b5N8TnUlt8KjU2ztBPnci4PyBQe96jswEbq5PNJJzwdv8q7WdmW cB0ePZLFZEB3PP4MSoSOgoLv2sNM2uKvcoO5Prxrct4pFI38Z8z1VodFiMkXuT7NA1v6N3E H1q2SwfnJKZPu2j5u8Yc7ckjgkb6O5oqLlheeWKAHIUPbcFVoKusPpFqBDyr33NqWeqoWG8 HETPPNOuXjuIJVj5IBcFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Rhu1RyjKnZA=:dTrlQqpWGqnqtjXwTgHUb9 wXsDOPA0VSmA0WemKw84U46LdycawlXg92d9dnHYT7fVMqVnXGlzXllANIJwDvj2ir0w328he pbPjj+/2kSYtHS2zXVLiqvGfSvZNZT7idhf2ZQcC6oxyBGZZhQy6m1QDoM7qCbLn2A5BOlLZB QHfyMGF1TbB+3c/NXENLQeswdYdprpw34UfcbIQnRDOQ4YwOhv0nZ7Kv9N1eZESBaSP1X3Yvf PjCuYyRd0YK+BlynLmSgFKbY/9YXeJQOffhOk5G3lx/mnu+NM/lx1wfEOUROAZpq6ubGIjhR1 zbFHpJj+TqJeu313g+2+YGIHTMVw4llctgZqe58AQY81oFw9Cw9hKV7kAx/lKdXpMWxg9snCz y9F15xUb498wvLkYrAZGJ9qAIeXdMzmscCDL1kvlzWOQs3PS5ahQFS3+oYVCbtD+dqqxIHUFi JW7yKO9p0LGoyjH+SjCfUbejIzr7g2Ua1ZBO9WzOWH157xOUXXyON/PzAe+I7rgOC1ZysUFSr 1SZ5l8fShNtMe1eHICdYh2kMwV7plwuC9mfXAxTdeMBqfD46lyISJ9FgTo33tDsJ3ULGBL3jz R4c/sl5qv3Nsiqcc7r4iRHiqEukBGjV4vk87H7vjuKfwrxe9X7cOvYyULfce6P/jc3JH7H9fb 7v6zkK3ruQhZYFLzVNC3jjcR43CDjFmkVZhDM2T/+6FDistW6LPTGMQUDab0xzRzC9kQPCdil c7fg2s0ZIACwVUyaXdkqiHTy2wJFe8zYVB4rDvvxTqQwVmJdAu507zBdp0csakpNXkjXSwoBx 6ggmW52 Archived-At: Subject: Re: [apps-discuss] Question about RFC 7239 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 20:27:56 -0000 On 2016-08-28 21:50, luigipinca@libero.it wrote: > Hello, > I have a question about the "Forwarded" HTTP header field, defined in > section 4 of RFC 7239. > The ABNF definition for the header field value is: > > Forwarded = 1#forwarded-element > > forwarded-element = > [ forwarded-pair ] *( ";" [ forwarded-pair ] ) > > forwarded-pair = token "=" value > value = token / quoted-string > > token = > quoted-string = > > If I'm reading this correctly, an empty forwarded-element or one made of > only ";" is a valid element. Nope. See . > ... Best regards, Julian From nobody Sun Aug 28 14:22:09 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA23C12B00A for ; Sun, 28 Aug 2016 14:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=libero.it 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 4V51i3XHwoKY for ; Sun, 28 Aug 2016 14:22:07 -0700 (PDT) Received: from libero.it (smtp-17.italiaonline.it [212.48.25.145]) (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 4FAAB127A90 for ; Sun, 28 Aug 2016 14:22:07 -0700 (PDT) Received: from webmail-56.iol.local ([10.255.25.88]) by smtp-17.iol.local with SMTP id e7Wkb8JpH681se7WkbMGwq; Sun, 28 Aug 2016 23:22:05 +0200 x-libjamoibt: 1601 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libero.it; s=s2014; t=1472419325; bh=ybS4kTBrR8U37h7CFgOglpjDkgW6WZP/WXoMiVhAUJg=; h=Date:From:Reply-To:To:Subject; b=p2s0NdX9amu0i1iIvR8vwSKvmR4zNUluBCxVIvCLKhMCrXPkK7hFITlnm3RYNeNiw Z/UBx9DnMlHXEPFGJrz5XtnJvQdEbX6gvpdB1Fp/sN8chGrmYrO4kvq9LgqHQ7YRal STRGxp8s71lhNfkgmnaO4DqJvqLRmyu4aAnc7qUm1SnBnBaSZH53uPtmX7F0kev34v 8ezEURI4qXzlojh+xgxhyPlmYWBJmU8ncL78haGI337wNXb88FSPH66j9T9TQW9mr+ hQCx8E+zSR8iiY1fdQ9f7wGlXReQQSdrBEdaswr4/H6n/wx9/2DtuFNvsSFEtdUvoL ZFWaVWEVIxebA== X-CNFS-Analysis: v=2.2 cv=LYJ+0XXi c=1 sm=1 tr=0 a=j7JVuU1FKh+ZZ1Jgs8mnSQ==:117 a=8D6cX0wMWuUA:10 a=Pfsz1xswR3AA:10 a=x1-6zHxI9d0A:10 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=6oWpXkWWAAAA:8 a=eXGqAOYZP252Kf6t_SgA:9 a=QEXdDO2ut3YA:10 a=Mi1i6eMwxqIA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=tJap5ArHYoT-Y_nFgk9U:22 Message-ID: <399542882.4083761472419322679.JavaMail.httpd@webmail-56.iol.local> Date: Sun, 28 Aug 2016 23:22:02 +0200 (CEST) From: "luigipinca@libero.it" To: Julian Reschke , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 212.124.190.235 X-libjamv: G1V9zckZIxo= X-libjamsun: +nchCLwTKBjpm2FxeTVV4Fz3pZQ3C24n X-CMAE-Envelope: MS4wfNEwfhRuvE0xkR6SBUF1PzLI+yeMS55sFhVxxqkw8RgLLmpvhcJ06Zd3ZuRXoRThdR0BqAC4PNXBLfHmul9OWukQ9uwFFGagezw3d6GM456abu3T/LmW QrIqzNwKCn618auUAhyKNCH9c+Maq5zg4/cRGgWH/lKPNBpP8ZBsFTCuCdGJ5omz5Zeq77Ccjw9lDK2mwp33HLjpwN+IilXEV+g= Archived-At: Subject: [apps-discuss] R: Re: Question about RFC 7239 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "luigipinca@libero.it" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 21:22:09 -0000 Thank you Julian but I still don't fully get it. According to the #rule extension as shown in your link, "foo , ,bar," is a valid value, so I assume that in our case "; , ," is also a valid value as forwarded-element is defined like this forwarded-element = [ forwarded-pair ] *( ";" [ forwarded-pair ] ) My main concern is actually on this definition. Why is forwarded-pair optional? Regards, Luigi >----Messaggio originale---- >Da: "Julian Reschke" >Data: 28/08/2016 22.27 >A: "luigipinca@libero.it", >Ogg: Re: [apps-discuss] Question about RFC 7239 > >On 2016-08-28 21:50, luigipinca@libero.it wrote: >> Hello, >> I have a question about the "Forwarded" HTTP header field, defined in >> section 4 of RFC 7239. >> The ABNF definition for the header field value is: >> >> Forwarded = 1#forwarded-element >> >> forwarded-element = >> [ forwarded-pair ] *( ";" [ forwarded-pair ] ) >> >> forwarded-pair = token "=" value >> value = token / quoted-string >> >> token = >> quoted-string = >> >> If I'm reading this correctly, an empty forwarded-element or one made of >> only ";" is a valid element. > >Nope. > >See . > > > ... > >Best regards, Julian > From nobody Sun Aug 28 16:22:18 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAE112D0A7 for ; Sun, 28 Aug 2016 16:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qtxWtmjlQTuD for ; Sun, 28 Aug 2016 16:22:15 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 4F57012B01A for ; Sun, 28 Aug 2016 16:22:15 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id x131so77722234ite.0 for ; Sun, 28 Aug 2016 16:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=afub5+z49J8FqQJzYfhkxeoNqV6uJBK9e6xGQVU2W7A=; b=YUINBQ0XarwZAkscTcfRKPkfAiypBTUCdxQspS+c4wDva6Hiyh8iI8NqNFWUOM7mbA bO4rgzc2kplnRqxncrenIZoqjE3g/M/XA82mLQ2zD48Xc5ZPHrXrJEzc8DfeSW5W3C1w eWYvQq9/agg6N1wmt84vmJTfbcdzQZyliUAau3qTLR12KKOiB4QHWP6jXSwe4TRbn5EB S16+yAmnoOZyw4Ns2DwfM093jR3v8tAS8n0Km5McACNr/zSa925SKIq/n8dyNicsXfin LlvZJUqVb7OvD9vT2qq1bTPFmYzaSLzOcLBRqmI42DLTlgW04mo/kbbc5YTo3WZRjFjm 7D9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=afub5+z49J8FqQJzYfhkxeoNqV6uJBK9e6xGQVU2W7A=; b=Jrz1SagL7ChosHQQ0a7rEqYMnVDN9RTK5ofXbw4K4PdxC1HN0hLYgY6CANxDGD0Qxt k5QRP1tF4dJuuT/5Z1ohaZ0ZceENBRLRnUJQ0hJtfQnRGhABSuLGLOGK+mWmZGRSQC12 fQo+n2PHeSjaqU+0v3BOFwxH2Z7WJ9kWVZiNVyIRgAGAPKLAy8vkwoqB1GoD5xfV3lij eyWsyRq4v2XiZGGu7bdh5bFnW3xQz4cMlxy/2th6LSR/VQ3CoeAvRd+0HVUGrOQAGnFD ELWZThGrrrdhQNlNz7uB4xYYGOJnn+kpUWXr2coRRVxKb3w5Y921iMHzS4Ie/qF4i3XJ p57Q== X-Gm-Message-State: AE9vXwNASyq43xvQ6ymPRBDAiChMNchcvBLP9PW2+jnEavdUcHEIpGMw5CCNyP+iU2hqPAR3fDtgiEbSobVS6w== X-Received: by 10.36.102.194 with SMTP id k185mr11577683itc.45.1472426534619; Sun, 28 Aug 2016 16:22:14 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.158.207 with HTTP; Sun, 28 Aug 2016 16:22:13 -0700 (PDT) In-Reply-To: <399542882.4083761472419322679.JavaMail.httpd@webmail-56.iol.local> References: <399542882.4083761472419322679.JavaMail.httpd@webmail-56.iol.local> From: Matthew Kerwin Date: Mon, 29 Aug 2016 09:22:13 +1000 X-Google-Sender-Auth: nVmcymj1nZE2327TP4D4xrcB6zE Message-ID: To: "luigipinca@libero.it" Content-Type: multipart/alternative; boundary=001a1147ab448dd1f8053b2a047e Archived-At: Cc: Julian Reschke , IETF Apps Discuss Subject: Re: [apps-discuss] R: Re: Question about RFC 7239 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 23:22:17 -0000 --001a1147ab448dd1f8053b2a047e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 August 2016 at 07:22, luigipinca@libero.it wrote: > Thank you Julian but I still don't fully get it. > According to the #rule extension as shown in your link, > > "foo , ,bar," > > is a valid value, so I assume that in our case > > "; , ," > > is also a valid value as forwarded-element is defined like this > > forwarded-element =3D [ forwarded-pair ] *( ";" [ forwarded-pair ] ) > > =E2=80=8BThe words in RFC 7230 say a lot more than the ABNF does. If you're concerned about the parser you should accept "a reasonable number of empty list elements"; but if you're generating headers you "MUST NOT generate empty list elements." The question, then, is whether ";" is a valid forwarded-element. I believe the intention was to make Forwarded be a list of lists, where the outer list (joined by commas) is as defined in RFC 7230, and the inner list (joined by semicolons) has the same semantics for ignoring a reasonable number of empty elements. To that end, within a single forwarded-element, this might be acceptable: " ;for=3D1.2.3.4;;proto=3Dhttp;" (Although I think you probably shouldn't generate such a value.) That said, that's only my reading. If it's the case, I suspect maybe it wasn't made clear enough in RFC 7239. > My main concern is actually on this definition. Why is forwarded-pair > optional? > > Regards, > > Luigi > =E2=80=8BCheers=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1147ab448dd1f8053b2a047e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 August 2016 at 07:22, luigipinca@libero.it <luigipinca@libero.it> wrote:
Thank you Ju= lian but I still don't fully get it.
According to the #rule extension as shown in your link,

"foo , ,bar,"

is a valid value, so I assume that in our case

"; , ,"

is also a valid value as forwarded-element is defined like this

forwarded-element =3D [ forwarded-pair ] *( ";" [ forwarded-pair = ] )


=E2=80=8BThe wor= ds in RFC 7230 say a lot more than the ABNF does. If you're concerned a= bout the parser you should accept "a reasonable number of empty list e= lements"; but if you're generating headers you "MUST NOT gene= rate empty list elements." The question, then, is whether ";" is a valid <= font style=3D"color:rgb(7,55,99)" face=3D"monospace, monospace">forwarded-e= lement.

I believe the intention was to make = Forwarded be a list of lists, where the outer list (joined by commas) is as= defined in RFC 7230, and the inner list (joined by semicolons) has the sam= e semantics for ignoring a reasonable number of empty elements.

To that end, within a single forwarded-element,= this might be acceptable: ";for=3D1.2.3.4;;proto=3Dhttp;" (Although I think you probabl= y shouldn't generate such a value.)

That said, that's only my reading. If it's the case, I suspect= maybe it wasn't made clear enough in RFC 7239.

=C2= =A0
My main concern is actually on this definition. Why is forwarded-pai= r
optional?

Regards,

Luigi

=E2=80=8BCheers=E2= =80=8B
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net= .au/
--001a1147ab448dd1f8053b2a047e-- From nobody Sun Aug 28 23:33:32 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6F812D13A for ; Sun, 28 Aug 2016 23:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 P9lrQeb2ne9O for ; Sun, 28 Aug 2016 23:33:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DEE12D12F for ; Sun, 28 Aug 2016 23:33:28 -0700 (PDT) Received: from [192.168.178.20] ([93.217.98.81]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MMjgF-1bl7M20yD9-008X3q; Mon, 29 Aug 2016 08:33:25 +0200 To: "luigipinca@libero.it" , apps-discuss@ietf.org References: <399542882.4083761472419322679.JavaMail.httpd@webmail-56.iol.local> From: Julian Reschke Message-ID: <412b3dc3-efdd-4a80-c7c4-e7d98c8516da@gmx.de> Date: Mon, 29 Aug 2016 08:33:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <399542882.4083761472419322679.JavaMail.httpd@webmail-56.iol.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fd2XvWbT754DcvhH+MvW1c1w5Grw+QG3J3wCL7nG76xjPb/cS8l vKZtTEwJGP30ON+nLo0i+6GVC8GYwlaIQz7SnI5JxApowSvDtnly+T8P8Hc6QrQPSkgNk+w lGrzFi/elYMcH8g0Hdqy2W2vbaT2GOFEBWIouojI+W3GfkxTfmLQQY816oiBXvJ1Wn3O5cS P/9oHKx5iQzxIP0ar8iDg== X-UI-Out-Filterresults: notjunk:1;V01:K0:D3sc2cPCNnk=:DjhiZnaWUy+Sx4nXD7Sr1X D61iu4N0r8ycQTHw/TGQ3cl/8Tn6aYT7/nMUTnM27I+Qabg1v3jGcSf3MX1zyNLJgyEDFuHEo /YzMhPDZVvsHrFIE8OaS9xT7c7eqpk4fDC3uwFb4D/DbePx9M+M3kkQkrLrxJBOAREbWEN9g4 w13R5QE3b9ltpL9AtVZu31k8KXJFyQB/RZisDzxvxnIJ0Ls7FDkmSeUpFDzaZKw+2NMiRqtBv 4/zu4Hsm7u1idOtZATnu3MfGT6+FjLT4b5XxZpQmgPn1YZxli5ZMaz31PVmi94XB5u2Vr5Fg5 6VO3NTmpBVeLpDEUQZJUnvu5NBgc99YvKDg0yxRCBZOTS/gu+U+PeyYa9/EhCmCVUCV4k+2nV 3MUsoJQj6Xb8epa5SZ2CqDIigwULZwWrjVX724tJkbmYnWEA4uHgmyOe6ekS/DZFPLWbgej1h YWuQ+MHZz26r72QGZIkOHLFy+5AcCcENg1tCX49J+gkE0l9Cv+ApnFazYQg+OKTLgQxlRKexM Hewjq1J5dX7VWNMA645ZkRJocBUqu1QpOrBNG3HYE/ktCM+4KDhIJwBUO+ydvrgRM3TCvaEyD xQGDIt1A/c7qHjCp7pIUOQBKFo7lrEadZ9foppe1aiUN25ETSc3HjfpqBncvcNpMLDNv5S6nR iiUrGgd8U3+yTmVE++tMId5dZHolJff9Hg4rk6/4KrftdRMIb51RFncNboAhSp/xjdCps+x29 yN9YGZN4ngkzulZ+Xz4qRtHdMVO5GNbdmDXUP0SVF9TENVEjZsK/p02nPRnBFQ2Q6DfOb8hW3 Ul0IuJA Archived-At: Subject: Re: [apps-discuss] R: Re: Question about RFC 7239 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 06:33:30 -0000 On 2016-08-28 23:22, luigipinca@libero.it wrote: > Thank you Julian but I still don't fully get it. > According to the #rule extension as shown in your link, > > "foo , ,bar," > > is a valid value, so I assume that in our case > > "; , ," > > is also a valid value as forwarded-element is defined like this > > forwarded-element = [ forwarded-pair ] *( ";" [ forwarded-pair ] ) > > My main concern is actually on this definition. Why is forwarded-pair > optional? > > Regards, > > Luigi > ... Ah, now I understand your concern - I was focusing on the HTTP ABNF list construct. Sorry, Julian From nobody Mon Aug 29 01:42:12 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C537712D137 for ; Mon, 29 Aug 2016 01:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 H1_GqT_FEceL for ; Mon, 29 Aug 2016 01:42:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A92812D133 for ; Mon, 29 Aug 2016 01:42:08 -0700 (PDT) Received: from [192.168.178.20] ([93.217.78.105]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MV1wf-1bcnck1jqv-00YNVB; Mon, 29 Aug 2016 10:42:03 +0200 To: IETF Apps Discuss From: Julian Reschke Message-ID: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> Date: Mon, 29 Aug 2016 10:42:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7ez3IwWTd/Qib7TBB1pXlXefIo11bFkmuDG3+TPVr0uDNoo17i5 wEAaoGvuGYNWXNENzVEZdHe7Syp8ffnWQxv7wryoCec47YnQgmPaMhWd5FeaaxYzntGAIH2 3vkvHcEXlrys907md2pxMzbj9jmLkl/UUCfwQCsHuSjrODxVFKDSKbVEXZluAD8kskNEGx6 ujgYywN0mylokiaKF1Q6Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:HsL62M5dIvE=:TVH7WK/DkjhQmKPVwAy7CT yZOmKbaGSzdAL6wyNTGiR34XdFEFRgDgd4BOwkSaxi1OflszpBADMa5VUcMfnfn/rjV5AD2A/ zcDHkLBPz7O98IgVIOhUC/cbUCpasPi5ArFOh4X17JZdjd0UiOK01B4uT3CnKqfLehQxzfyp3 4Kh2kgBquvrk2PTOznyZ7B3lU6Xm+MjY9B474xRPXhwdIX5jpFgmluRfrxvFFXlSHQZbFmgQA Hzi81wPJ0wQbkQMESWUIVvASIeu15X4C05Bb1bdIl5TwRI9hHtFCkpJJnCMAUzyhMN736EmPK jyBXkyEfRxtFo0iLAxLne4VM1kd9SyHSzIoD75DrGUOpbxGqQUmE7qPT1AQSztDXKzKLqO3B7 2QWxNlhsRYSIh4VJKabkPkQiVqAVn9r3sD0v8M1ggbEisPKJuPMt27CbgZUZ+tfryJVtUZBfh 92/nHTiA9OuL0kjzcVzoOF4CsEtqLGoikRsBsjUo3hy7fsyaKUtVbP27URZthOqvCGWQl3gN2 h0OD5Mq/qlfaVFIu/qSGWLW1do24W5JkWuZVQnMMxinoDjeuhNMX44i4A5lasAZs6K1zscpDr 5XgBjYoC4YUDFi6m3XlAOnpRdYbGunH4NJr/DkHzarmZOdg5EcXlwqMgtkaY+vVHZd6n/fdmR dgzySimGpaGoI2v4CmfWQdbA0cLruZjGHBrVvs6tjtTZ7HhfRi1s0j/wnsEW61+n4aYZnYJpm MBMgZ3FPF11kNp7iEaUhHNCsAh8H7gTg9gUJ2swqIgReuPl9Owo2ZuYepFC96njnFZYP0zbdt lMvPQVzGiiA0cvya6JOF4rHdht53Sn5Ui4TzfPHNl3uP27+LfdRI3V7a+gyRh0BsfbysudX0L ZYSaoyGcwhjb42kLhF45/+bBZKqgxileYZxBk0NEe8O2zwipPozpzmGjt+hJ68stdZhkaq+eo 2vwBHvoBTDk2awA9EQN7dS3+vHYA31L8xCJ3WBr7wa8biwokBVt1X Archived-At: Subject: [apps-discuss] URI templates in Link header fields X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 08:42:11 -0000 Hi there. RFC 5988, defining the HTTP Link header field, predates RFC 6570, defining URI templates. In the meantime, I heard of a few cases where people were trying to use templates in Link header fields (an obvious thing to do), and came up with hacks to do so with the existing Link header field. I'm tempted to work on a small spec that defines an experimental new header field, similar to Link but allowing templates. Is anybody aware of existing code trying to use templates in Link header fields? If so, please report over here (or in doubt send private email). Best regards, Julian From nobody Mon Aug 29 08:30:53 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4D612D78C for ; Mon, 29 Aug 2016 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net 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 10epuY_zgYct for ; Mon, 29 Aug 2016 08:30:51 -0700 (PDT) Received: from postoffice.gristmillmedia.com (postoffice.gristmillmedia.com [96.30.18.196]) (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 9527D12D77F for ; Mon, 29 Aug 2016 08:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Nz4oE9Mag1+buYkDFEXtep+PlEEvv3bi87DnEEKHcQU=; b=0LTSa7IcmdCCka+EsVKT9AAlyc H1Y3I9WFAoIw2QR7/RuhVJvmE7Az8rl/RbPy98tzsFCyts3DVbk4GOSn+WI/azuFYjjdJwSGyHEnt YVIFFaL4JxmyiMl1SXwAq1Ve2XabD+ZS4Tbhirr52XehnE4RHZ3/aA4DO/reIvOuqdcyWKUx3vKmN BxpdPrp7HLKPLLFvV9WwgjQIwA7PNTkv+N3m7PxsIj6kD+8WwxRK7Syx/LarRY8XYYFRL1jyxe7CF JNQaYpIPfS1RaEq6yhNZki9uv55CaP1SfZT6RGEjNRfEib/9yhKjaxS0BeQqZ6cgaW2p39jND0avO 7fuz09+w==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:58739 helo=[192.168.1.77]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1beOWQ-0000RV-AA; Mon, 29 Aug 2016 11:30:50 -0400 To: Julian Reschke , IETF Apps Discuss References: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> From: Erik Wilde Message-ID: Date: Mon, 29 Aug 2016 08:30:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [apps-discuss] URI templates in Link header fields X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 15:30:53 -0000 hello julian On 2016-08-29 01:42, Julian Reschke wrote: > In the meantime, I heard of a few cases where people were trying to use > templates in Link header fields (an obvious thing to do), and came up > with hacks to do so with the existing Link header field. > I'm tempted to work on a small spec that defines an experimental new > header field, similar to Link but allowing templates. @mnot has been working on collecting ideas for an update to RFC 5988 for a while now. maybe that's one more motivation to go forward with this? i'd certainly be willing to put in some time to get it off the ground. https://github.com/mnot/I-D/issues?q=is%3Aissue+is%3Aopen+label%3Arfc5988bis > Is anybody aware of existing code trying to use templates in Link header > fields? If so, please report over here (or in doubt send private email). this is not really code, but people want to use URI templates and there have been some efforts to provide a context that makes that more easy: - @mnot's https://tools.ietf.org/html/draft-nottingham-link-hint - my own https://tools.ietf.org/html/draft-wilde-link-desc - part of the JSON home model: https://tools.ietf.org/html/draft-nottingham-json-home#section-3.1 if i recall correctly all of these have slightly different use cases and models, but (unsurprisingly) also a lot of overlap. it would be great to consolidate all of this so that tooling and implementations can rely on a robust spec. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Mon Aug 29 09:36:14 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16E012B00B for ; Mon, 29 Aug 2016 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 f8ifcN8yLoB9 for ; Mon, 29 Aug 2016 09:36:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44C612B005 for ; Mon, 29 Aug 2016 09:36:11 -0700 (PDT) Received: from [192.168.178.20] ([93.217.78.105]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LdKs1-1bEONx1Nx3-00iTJ3; Mon, 29 Aug 2016 18:35:24 +0200 To: Erik Wilde , IETF Apps Discuss References: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> From: Julian Reschke Message-ID: <865f01b1-9c3e-e767-f3f0-ece2fe4f0087@gmx.de> Date: Mon, 29 Aug 2016 18:35:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Nntq4bxI4wIg4cAY18pMRhPo5rwYTnG4LoqRnl6Vfr0gXlauD/G diiAq7DYHWEbjdGDeL19L7wfMDL06xjKTCH3OMKgZq4xIxrHOaWawiVruONcKSxlfQYvsHY pYiMj2izcMkmLvtNPsXP/O594+MfGTfh3LyQlwC273HCc1+SJ2vOvcKmMt0WJn/faOWuJps aaTQsJNEsSiFXc0lySTXw== X-UI-Out-Filterresults: notjunk:1;V01:K0:b3LV0dlFe/g=:aBdVD/0DKXxSIZZX3OAOMi r8/84Vw15pmiCVXsQ75nyzxiT7lU+C7Zq3kLSMzMxEBxZzR5d7yEJXDYPc7J3OVfr1Y2KMFaT rxyxE6fSHlLfSWCyvKFNAd+Is4HdvHgPKc/SxmTiLQcskXuo8lMV0X8siU2XFlYxGSiuUs9Kf HBcANZQIZMpb57OfJ9uzLLnAbeKRvbCow0BRnshp0c/CgFdND7W37WEcddhgvgCB+eVrGf6uL LvIHtrmAj5QAfcQicQ2Pm+KmK5cmb4G8q1ZxFdiaTdF4/4c0yMz8y57gMiVpjh4hZGS1u6tg7 7S/Rh6qGGEGH0ZjjgyGsXU+HEZE2GTnP8QitRNAmXW84+OHe09+ZgJHcJi5KnFnQWI35I2m6g I2+Xx7OZ2QTUXeKWacXON+CkvJPVbHnE7twRINuBL/J/quOpsnYwyWFm71MeS6f2FNG7eeJHK n4p4n/lCON8vnLeQgKd94v6g0WR36KtkI1Ih6MH/+CqBaOMtkel9RK4jUwaJ392g+ULYeC9LF 5MP+QONwUzlyhzQSOVDkBCVKyscl6GtDazWOn5B0zZ0dIu1lIspBPvESWZd+Ue7BmzszU3cwh SybTSjjkPcxDXI9uWqNuahSSJ1lji0TQ+JUJ/wAiDW65CwCYHluQD32DufcdWma3F/SO8Bhpk WSNLQMnVZ4TbQurr0SoTTWdjD8cd3RMP4zPPNzN9cs2Ldgi5OmR3YhiPy7k1nP6yvd+ikRZIu 1+U/+ZXLELOSKXrM7vSxdQswBafcW/R/XDKqm6C1wyZ5Ol7+RIIzKaI059NYPLHvjB4OIwTYN OaKJfhA Archived-At: Subject: Re: [apps-discuss] URI templates in Link header fields X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 16:36:14 -0000 On 2016-08-29 17:30, Erik Wilde wrote: > hello julian > > On 2016-08-29 01:42, Julian Reschke wrote: >> In the meantime, I heard of a few cases where people were trying to use >> templates in Link header fields (an obvious thing to do), and came up >> with hacks to do so with the existing Link header field. >> I'm tempted to work on a small spec that defines an experimental new >> header field, similar to Link but allowing templates. > > @mnot has been working on collecting ideas for an update to RFC 5988 for > a while now. maybe that's one more motivation to go forward with this? > i'd certainly be willing to put in some time to get it off the ground. > > https://github.com/mnot/I-D/issues?q=is%3Aissue+is%3Aopen+label%3Arfc5988bis Yep, I'm aware of that... >> Is anybody aware of existing code trying to use templates in Link header >> fields? If so, please report over here (or in doubt send private email). > > this is not really code, but people want to use URI templates and there > have been some efforts to provide a context that makes that more easy: > > - @mnot's https://tools.ietf.org/html/draft-nottingham-link-hint > > - my own https://tools.ietf.org/html/draft-wilde-link-desc > > - part of the JSON home model: > https://tools.ietf.org/html/draft-nottingham-json-home#section-3.1 > > if i recall correctly all of these have slightly different use cases and > models, but (unsurprisingly) also a lot of overlap. it would be great to > consolidate all of this so that tooling and implementations can rely on > a robust spec. Agreed. Thanks for the feedback, Julian From nobody Tue Aug 30 05:33:56 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A3D12D507 for ; Tue, 30 Aug 2016 05:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 n2T03evPqSUC for ; Tue, 30 Aug 2016 05:33:53 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE78D12D501 for ; Tue, 30 Aug 2016 05:33:52 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1beiEh-0005Cw-nJ; Tue, 30 Aug 2016 13:33:51 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=sasharissa.local) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1beiEh-0003Ly-DV; Tue, 30 Aug 2016 13:33:51 +0100 Message-ID: <57C57D2D.30302@ninebynine.org> Date: Tue, 30 Aug 2016 13:33:49 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , IETF Apps Discuss References: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> In-Reply-To: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] URI templates in Link header fields X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 12:33:54 -0000 Hi! I've wanted something like this in the past, and I *thought* I had some code that accepted a template in a custom header field. But on closer examination, I see that I passed a template in the body of a POST submission. It's something I could see myself using if specified. And +1 to Erik Wilde's comment: "it would be great to consolidate all of this so that tooling and implementations can rely on a robust spec". #g -- On 29/08/2016 09:42, Julian Reschke wrote: > Hi there. > > RFC 5988, defining the HTTP Link header field, predates RFC 6570, defining URI > templates. > > In the meantime, I heard of a few cases where people were trying to use > templates in Link header fields (an obvious thing to do), and came up with hacks > to do so with the existing Link header field. > > I'm tempted to work on a small spec that defines an experimental new header > field, similar to Link but allowing templates. > > Is anybody aware of existing code trying to use templates in Link header fields? > If so, please report over here (or in doubt send private email). > > Best regards, Julian > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Aug 30 10:08:31 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501C12D608 for ; Tue, 30 Aug 2016 10:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 9o6CAfEI16O6 for ; Tue, 30 Aug 2016 10:08:26 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 BEBB712B039 for ; Tue, 30 Aug 2016 10:08:26 -0700 (PDT) Received: from [10.0.3.253] (unknown [209.49.225.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 827A122E257; Tue, 30 Aug 2016 13:08:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: <865f01b1-9c3e-e767-f3f0-ece2fe4f0087@gmx.de> Date: Tue, 30 Aug 2016 09:41:21 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <64FC8E9D-03A2-496D-B382-612364F86C99@mnot.net> References: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> <865f01b1-9c3e-e767-f3f0-ece2fe4f0087@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] URI templates in Link header fields X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:08:29 -0000 See also: https://www.ietf.org/archive/id/draft-nottingham-link-template-01.txt > On 30 Aug 2016, at 2:35 AM, Julian Reschke = wrote: >=20 > On 2016-08-29 17:30, Erik Wilde wrote: >> hello julian >>=20 >> On 2016-08-29 01:42, Julian Reschke wrote: >>> In the meantime, I heard of a few cases where people were trying to = use >>> templates in Link header fields (an obvious thing to do), and came = up >>> with hacks to do so with the existing Link header field. >>> I'm tempted to work on a small spec that defines an experimental new >>> header field, similar to Link but allowing templates. >>=20 >> @mnot has been working on collecting ideas for an update to RFC 5988 = for >> a while now. maybe that's one more motivation to go forward with = this? >> i'd certainly be willing to put in some time to get it off the = ground. >>=20 >> = https://github.com/mnot/I-D/issues?q=3Dis%3Aissue+is%3Aopen+label%3Arfc598= 8bis >=20 > Yep, I'm aware of that... >=20 >>> Is anybody aware of existing code trying to use templates in Link = header >>> fields? If so, please report over here (or in doubt send private = email). >>=20 >> this is not really code, but people want to use URI templates and = there >> have been some efforts to provide a context that makes that more = easy: >>=20 >> - @mnot's https://tools.ietf.org/html/draft-nottingham-link-hint >>=20 >> - my own https://tools.ietf.org/html/draft-wilde-link-desc >>=20 >> - part of the JSON home model: >> https://tools.ietf.org/html/draft-nottingham-json-home#section-3.1 >>=20 >> if i recall correctly all of these have slightly different use cases = and >> models, but (unsurprisingly) also a lot of overlap. it would be great = to >> consolidate all of this so that tooling and implementations can rely = on >> a robust spec. >=20 > Agreed. >=20 > Thanks for the feedback, Julian >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 30 10:50:35 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E2D12B01B for ; Tue, 30 Aug 2016 10:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=unavailable 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 e9aXzMBWWar7 for ; Tue, 30 Aug 2016 10:50:33 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 456E012D608 for ; Tue, 30 Aug 2016 10:41:22 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6BA38509B6 for ; Tue, 30 Aug 2016 13:41:21 -0400 (EDT) To: apps-discuss@ietf.org References: <410cba92-83fa-8e4c-73ff-ac97ea5f8d32@gmx.de> <57C57D2D.30302@ninebynine.org> From: Sean Leonard Message-ID: <15e3df96-b806-fe96-03a8-f564af25f1e5@seantek.com> Date: Tue, 30 Aug 2016 10:41:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57C57D2D.30302@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [apps-discuss] URI templates in Link header fields X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:50:34 -0000 Overall it's a good idea, so +1 to the effort (to add URI template support to HTTP Links). I give +½ to the consolidation comment. It would be good to consolidate, but I do not know if consolidating to one spec would put excessive burdens on diverse implementations that only need selected features (i.e., to support all features). Lack of knowledge of this space, that's all. Regards, Sean On 8/30/2016 5:33 AM, Graham Klyne wrote: > Hi! > > I've wanted something like this in the past, and I *thought* I had > some code that accepted a template in a custom header field. But on > closer examination, I see that I passed a template in the body of a > POST submission. > > It's something I could see myself using if specified. > > And +1 to Erik Wilde's comment: "it would be great to consolidate all > of this so that tooling and implementations can rely on a robust spec". > > #g > -- > > > On 29/08/2016 09:42, Julian Reschke wrote: >> Hi there. >> >> RFC 5988, defining the HTTP Link header field, predates RFC 6570, >> defining URI >> templates. >> >> In the meantime, I heard of a few cases where people were trying to use >> templates in Link header fields (an obvious thing to do), and came up >> with hacks >> to do so with the existing Link header field. >> >> I'm tempted to work on a small spec that defines an experimental new >> header >> field, similar to Link but allowing templates. >> >> Is anybody aware of existing code trying to use templates in Link >> header fields? >> If so, please report over here (or in doubt send private email). >> >> Best regards, Julian