From nobody Mon Feb 6 03:03:55 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EA2129CCF for ; Mon, 6 Feb 2017 03:03:54 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=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 WjvB-FOy4j9W for ; Mon, 6 Feb 2017 03:03:52 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6176812953E for ; Mon, 6 Feb 2017 03:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486379031; d=isode.com; s=june2016; i=@isode.com; bh=AnyEc5RmymPr7XVONokWVNUhehCpmedvB4McM5KlEFw=; 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=nJlZxwpYJp5HB9hBWl7r/lx88DGws2XLNieTEeKlycoyLHrFQGZwjZZwGOlcCsSqFnFI7U anz0+DOpWafx+om49GN4NXiMCmaHhSLQbmORqMAO6q8IdMWrUqz2fPLka9Bz57HsRARVJK jrEMo6aqq/ng6xtpMg8V8SiHj+ia4wE=; 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 ; Mon, 6 Feb 2017 11:03:51 +0000 References: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> To: art@ietf.org From: Alexey Melnikov X-Forwarded-Message-Id: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> Message-ID: <79a5db6b-b952-1d1b-8513-d9f250fffe98@isode.com> Date: Mon, 6 Feb 2017 11:03:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <148616796247.4079.7104562493351135409.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E276EF2C1C5FBFDDE3D9BA71" Archived-At: Subject: [art] Fwd: WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 11:03:54 -0000 This is a multi-part message in MIME format. --------------E276EF2C1C5FBFDDE3D9BA71 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I believe the charter text addressed comments raised on this mailing list, as well as on ietf-smtp and imapext. -------- Forwarded Message -------- Subject: WG Review: JSON Mail Access Protocol (jmap) Date: Fri, 03 Feb 2017 16:26:02 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: jmap@ietf.org A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2017-02-13. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Ben Campbell Alissa Cooper Alexey Melnikov Mailing list: Address: jmap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Group page: https://datatracker.ietf.org/group/jmap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/ A number of JSON-based representations of email have been developed that are proprietary, non-standard, and incompatible with each other. These protocols are proliferating due to existing standards being insufficient or poorly suited to the environments they are operating in, particularly mobile and webmail. The use of multiple protocols to perform actions within a single application creates significant support challenges, as users may get a variety of partial failure modes (for example, can receive email, but can not send new messages). This is further exacerbated if the different protocols are authenticated separately. The JMAP working group will specify a mechanism to allow clients to both view and send email from a server over a single stateless HTTPS channel with minimal round trips. A single protocol for receipt and submission will resolve long-standing difficulties users face setting up clients to talk to servers. The protocol will support push notification of changes using the mechanism defined in RFC 8030. This will give mobile clients benefits in terms of battery life and network usage. It will also support push notifications via server-sent events (https://www.w3.org/TR/eventsource/) for direct connection to clients that can support persistent TCP connections. The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. New end-to-end encryption mechanisms are out of scope, but the work should consider how to integrate with existing standards such as S/MIME and OpenPGP. The working group will coordinate with the Security Area on credential management and authentication. Input to working group discussions shall include: - CONDSTORE and QRESYNC [RFC 7162] - Collection Synchronisation for WebDav [RFC 6578] - LEMONADE and experiences from adoption of its output [https://datatracker.ietf.org/wg/lemonade/charter/] - SMTP SUBMISSION [RFC 6409] - SMTP BURL [RFC 4468] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on a new protocol for client to server email synchronisation. The working group may choose not to publish this as an RFC. - A document describing an extensible protocol and data structures, with support for flood control and batched operations, and operating over a stateless connection such as HTTPS. - A document describing how to use the extensible protocol over HTTPS with the data structures expressed as JSON. - A document describing a data model for email viewing, management, searching, and submission on top of the extensible protocol. - An executable test suite and documented test cases to assist developers of JMAP servers to ensure they conform to the specifications. Milestones: --------------E276EF2C1C5FBFDDE3D9BA71 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

I believe the charter text addressed comments raised on this mailing list, as well as on ietf-smtp and imapext.

-------- Forwarded Message --------
Subject: WG Review: JSON Mail Access Protocol (jmap)
Date: Fri, 03 Feb 2017 16:26:02 -0800
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF-Announce <ietf-announce@ietf.org>
CC: jmap@ietf.org 


A new IETF WG has been proposed in the Applications and Real-Time Area.
The IESG has not made any determination yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (iesg@ietf.org) by
2017-02-13.

JSON Mail Access Protocol (jmap)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  TBD

Assigned Area Director:
  Alexey Melnikov <aamelnikov@fastmail.fm>

Applications and Real-Time Area Directors:
  Ben Campbell <ben@nostrum.com>
  Alissa Cooper <alissa@cooperw.in>
  Alexey Melnikov <aamelnikov@fastmail.fm>
 
Mailing list:
  Address: jmap@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/jmap
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap

Group page: https://datatracker.ietf.org/group/jmap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/

A number of JSON-based representations of email have been developed
that are proprietary, non-standard, and incompatible with each other.
These protocols are proliferating due
to existing standards being insufficient or poorly suited to the
environments they are operating in, particularly mobile and webmail.

The use of multiple protocols
to perform actions within a single application creates significant
support challenges, as users may get a variety of partial failure modes
(for example, can receive email, but can not send new messages).
This is further exacerbated if the different protocols are
authenticated separately.

The JMAP working group will specify a mechanism to allow clients to
both view and send email from a server over a single stateless HTTPS
channel with minimal round trips. A single protocol for receipt and
submission will resolve long-standing difficulties users face
setting up clients to talk to servers.

The protocol will support
push notification of changes using the mechanism defined in RFC 8030.
This will give mobile clients benefits in terms of battery life and
network usage. It will also support push notifications via server-sent
events (https://www.w3.org/TR/eventsource/) for direct connection to
clients that can support persistent TCP connections.

The work of this group is limited to developing a protocol for a client
synchronising data with a server. Any server-to-server issues
are out of scope for this working group.
New end-to-end encryption mechanisms are out of scope, but the work
should
consider how to integrate with existing standards such as S/MIME and
OpenPGP.

The working group will coordinate with the Security Area on credential
management and authentication.

Input to working group discussions shall include:

- CONDSTORE and QRESYNC
[RFC 7162]

- Collection Synchronisation for WebDav
[RFC 6578]

- LEMONADE and experiences from adoption of its output
[https://datatracker.ietf.org/wg/lemonade/charter/]

- SMTP SUBMISSION
[RFC 6409]

- SMTP BURL
[RFC 4468]

The working group will deliver the following:

- A problem statement detailing the deployment environment and
  situations that motivate work on a new protocol for client to
  server email synchronisation.  The working group may choose
  not to publish this as an RFC.

- A document describing an extensible protocol and data structures, with
  support for flood control and batched operations, and operating over
  a stateless connection such as HTTPS.

- A document describing how to use the extensible protocol over HTTPS
  with the data structures expressed as JSON.

- A document describing a data model for email viewing, management,
  searching, and submission on top of the extensible protocol.

- An executable test suite and documented test cases to assist
  developers of JMAP servers to ensure they conform to the
  specifications.

Milestones:
--------------E276EF2C1C5FBFDDE3D9BA71-- From nobody Mon Feb 6 07:41:19 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F70129E41 for ; Mon, 6 Feb 2017 07:41:17 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=o4UaPztP; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=IDgklCfn 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 pLVKqaH3KI0E for ; Mon, 6 Feb 2017 07:41:12 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F49129E81 for ; Mon, 6 Feb 2017 07:41:10 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 577D320524; Mon, 6 Feb 2017 10:41:10 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 06 Feb 2017 10:41:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= mesmtp; bh=SPZA+7aWl0XKoEWNNysmErXVEIQ=; b=o4UaPztP8IBKDO31BNN1r 3DCHhLIgPMagKhgujJtGpCzEKTOWztulia3PLZQrCxDI2PPs/YYSaMNiduDWXgcd NahLO72uaSTGQ9lO9uKEbnQmIcyy+YRblCfjXRxDWZJnig+Y+EgQVj47ePpLqQCj msENENPjyu7Nhcfgc1EM1E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc:x-sasl-enc; s=smtpout; bh=SPZA+7aWl0XKoEWNNysmErXVEI Q=; b=IDgklCfnJQ9Z2mOwXCbvXbvQe0naOyGwOJd2tuNRBRbNAkK7IX0rNRZRXu ogWitm1ETLTDcp/ERMaV6JT1KRTXevxEJMUo8DZDYmCNT9KOIPezqVKj9Ks/U6rB Ex3pS/mJJyurDdlzQzphFd4UR2eEVSclBfekZmvMOOffJPbj0= X-ME-Sender: X-Sasl-enc: LSPIJeaY0val5bK6SwlJi0XFUIxAv6svwx1paqocckYj 1486395669 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 614907E187; Mon, 6 Feb 2017 10:41:09 -0500 (EST) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_D854EB75-56FE-4C95-A5A0-8DFAF3E54D7A" Message-Id: <9BA325F5-E77F-45DE-A398-B247F4895F94@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 6 Feb 2017 10:41:08 -0500 References: To: art@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ben@nostrum.com, Alexey Melnikov Subject: [art] ART AD coverage X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:41:17 -0000 --Apple-Mail=_D854EB75-56FE-4C95-A5A0-8DFAF3E54D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Per the announcements below, Alissa will be vacating her ART AD seat at = IETF 98. If an incoming AD is selected to fill the vacancy by that time, = we will handle the AD transition as usual, with the continuing ADs = helping the new person get up-to-speed, and possibly with some = reshuffling of WG assignments amongst the three ART ADs. If an incoming = AD has not been selected by that time, Alexey and Ben will take = responsibility for shepherding all the ART WGs temporarily until a third = AD gets seated. Please let us know if you have questions. Thanks, Alexey, Ben, and Alissa > Begin forwarded message: >=20 > From: Lucy Lynch > Subject: Re: NomCom 2016-2017 - Announcement of IESG selections > Date: February 3, 2017 at 5:03:15 PM EST > To: Alissa Cooper > Cc: ietf@ietf.org, IETF Announcement List >=20 > On Fri, 3 Feb 2017, Alissa Cooper wrote: >=20 >> In light of this announcement, I will be resigning as ART AD = effective during IETF 98 when I assume the Gen AD/IETF Chair position. I = am willing to overlap with an incoming ART AD should the vacancy be = filled prior to then. >=20 > Thanks for this confirmation Alissa. The NomCom will convene this next = week to begin the process to appoint a replacement for the up-coming = vacancy. >=20 > We will post an open call for nominations after our meeting and we = believe that we can meet the conditions as outlined in RFC 7437 Section = 3.5. We will also post our six week calendar allowing time for = nominations, feedback, interviews, selection, and confirmation. >=20 > Best - >=20 > Lucy Lynch > NomCom Chair 2016-2017 >=20 >=20 >> Alissa >>=20 >>> On Jan 31, 2017, at 11:22 AM, NomCom Chair 2016 = wrote: >>>=20 >>> As chair of the 2016-2017 NomCom, it is my pleasure to announce the >>> selection of IESG members to serve in the 2017-2019 cycle. >>>=20 >>> The selected candidates are: >>>=20 >>> Alissa Cooper, Chair >>> Ben Campbell, ART AD >>> Terry Manderson, INT AD >>> Warren Kumari, OPS AD >>> Alvaro Retana, RTG AD >>> Deborah Brungard, RTG AD >>> Eric Rescorla, SEC AD >>> Spencer Dawkins, TSV AD >>>=20 >>> The resulting IESG will consist of: >>>=20 >>> Alissa Cooper, Cisco, Chair >>> Ben Campbell, Oracle, ART AD >>> Alexey Melnikov, Isode, ART AD >>> Suresh Krishnan, Ericsson, Internet AD >>> Terry Manderson, ICANN, Internet AD >>> Benoit Claise, Cisco, Management AD (O&M AD) >>> Warren Kumari, Google, Operations AD (O&M AD) >>> Alia Atlas, Juniper Networks, Routing AD >>> Deborah Brungard, AT&T, Routing AD >>> Alvaro Retana, Cisco, Routing AD >>> Kathleen Moriarty, EMC Corporation, Security AD >>> Eric Rescorla, Mozilla, SEC AD >>> Mirja Kuhlewind, ETH Zurich, Transport AD >>> Spencer Dawkins, Wonder Hamster Internetworking, Transport AD >>>=20 >>> The Nomcom of one year ago noted that the IESG would have 3 >>> members from Cisco. This year's IESG makes no changes in this = regard. >>> We have had no reports that this has caused any issues over the past >>> year, and hope that this continues to remain true in the coming = year. >>>=20 >>> The IAB and IAOC selections will be announced after completing the >>> confirmation procedure. >>>=20 >>> The Nomcom wishes to thank everyone who volunteered, everyone who >>> nominated, and everyone who provided feedback to the process. Your >>> input was vital in coming to this set of decisions. >>>=20 >>> Lucy Lynch >>> Nomcom chair 2016-2016 >>> llynch @ civil-tongue.net >>>=20 >>=20 >>=20 >>=20 --Apple-Mail=_D854EB75-56FE-4C95-A5A0-8DFAF3E54D7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Per the announcements below, Alissa will be = vacating her ART AD seat at IETF 98. If an incoming AD is selected to = fill the vacancy by that time, we will handle the AD transition as = usual, with the continuing ADs helping the new person get up-to-speed, = and possibly with some reshuffling of WG assignments amongst the three = ART ADs. If an incoming AD has not been selected by that time, Alexey = and Ben will take responsibility for shepherding all the ART WGs = temporarily until a third AD gets seated.

Please let us know if you have = questions.

Thanks,
Alexey, = Ben, and Alissa


Begin = forwarded message:

From: = Lucy Lynch <llynch@civil-tongue.net>
Subject: = Re: NomCom = 2016-2017 - Announcement of IESG selections
Date: = February 3, 2017 at 5:03:15 PM = EST
To: = Alissa Cooper <alissa@cooperw.in>
Cc: = ietf@ietf.org, IETF Announcement List <ietf-announce@ietf.org>

On Fri, 3 Feb 2017, Alissa = Cooper wrote:

In light of this announcement, I will be resigning as ART AD = effective during IETF 98 when I assume the Gen AD/IETF Chair position. I = am willing to overlap with an incoming ART AD should the vacancy be = filled prior to then.

Thanks = for this confirmation Alissa. The NomCom will convene this next week to = begin the process to appoint a replacement for the up-coming vacancy.

We will post an open call for nominations = after our meeting and we believe that we can meet the conditions as = outlined in RFC 7437 Section 3.5. We will also post our six week = calendar allowing time for nominations, feedback, interviews, selection, = and confirmation.

Best -

Lucy Lynch
NomCom Chair 2016-2017


Alissa

On Jan 31, 2017, at 11:22 AM, NomCom Chair 2016 <nomcom-chair-2016@ietf.org> wrote:

As chair of the 2016-2017 NomCom, it is my pleasure to = announce the
selection of IESG members to serve in the = 2017-2019 cycle.

The selected candidates = are:

Alissa Cooper, Chair
Ben = Campbell, ART AD
Terry Manderson, INT AD
Warren Kumari, OPS AD
Alvaro Retana, RTG AD
Deborah Brungard, RTG AD
Eric Rescorla, SEC = AD
Spencer Dawkins, TSV AD

The = resulting IESG will consist of:

Alissa = Cooper, Cisco, Chair
Ben Campbell, Oracle, ART AD
Alexey Melnikov, Isode, ART AD
Suresh Krishnan, = Ericsson, Internet AD
Terry Manderson, ICANN, Internet = AD
Benoit Claise, Cisco, Management AD (O&M AD)
Warren Kumari, Google, Operations AD (O&M AD)
Alia Atlas, Juniper Networks, Routing AD
Deborah = Brungard, AT&T, Routing AD
Alvaro Retana, Cisco, = Routing AD
Kathleen Moriarty, EMC Corporation, Security = AD
Eric Rescorla, Mozilla, SEC AD
Mirja = Kuhlewind, ETH Zurich, Transport AD
Spencer Dawkins, = Wonder Hamster Internetworking, Transport AD

The Nomcom of one year ago noted that the IESG would have = 3
members from Cisco. This year's IESG makes no changes in = this regard.
We have had no reports that this has caused = any issues over the past
year, and hope that this = continues  to remain true in the coming year.

The IAB and IAOC selections will be announced after = completing the
confirmation procedure.

The Nomcom wishes to thank everyone who volunteered, everyone = who
nominated, and everyone who provided feedback to the = process. Your
input was vital in coming to this set of = decisions.

Lucy Lynch
Nomcom = chair 2016-2016
llynch @ civil-tongue.net





= --Apple-Mail=_D854EB75-56FE-4C95-A5A0-8DFAF3E54D7A-- From nobody Fri Feb 17 20:36:13 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669FF129704; Fri, 17 Feb 2017 20:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 b9FvhW9GmDja; Fri, 17 Feb 2017 20:36:10 -0800 (PST) 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 74098129463; Fri, 17 Feb 2017 20:36:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6954BB812CD; Fri, 17 Feb 2017 20:36:10 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170218043610.6954BB812CD@rfc-editor.org> Date: Fri, 17 Feb 2017 20:36:10 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, art@ietf.org, rfc-editor@rfc-editor.org Subject: [art] RFC 8089 on The "file" URI Scheme X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 04:36:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8089 Title: The "file" URI Scheme Author: M. Kerwin Status: Standards Track Stream: IETF Date: February 2017 Mailbox: matthew.kerwin@qut.edu.au Pages: 19 Characters: 36893 Updates: RFC 1738 I-D Tag: draft-ietf-appsawg-file-scheme-16.txt URL: https://www.rfc-editor.org/info/rfc8089 DOI: 10.17487/RFC8089 This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738. It defines a common syntax that 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. This document is a product of the ART Area General Application Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Feb 18 07:08:55 2017 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917812952D for ; Sat, 18 Feb 2017 07:08:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148743053329.22740.10912549170613348999.idtracker@ietfa.amsl.com> Date: Sat, 18 Feb 2017 07:08:53 -0800 From: IETF Secretariat Archived-At: Subject: [art] Milestones changed for appsawg WG X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 15:08:53 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-file-scheme", resolved as "Done". Changed milestone "Publication requested for draft-ietf-appsawg-mdn-3798bis", resolved as "Done". URL: https://datatracker.ietf.org/wg/appsawg/charter/ From nobody Thu Feb 23 07:31:37 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B58D1299CF; Thu, 23 Feb 2017 07:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PbYLb0onO_k; Thu, 23 Feb 2017 07:31:35 -0800 (PST) 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 10E621299CD; Thu, 23 Feb 2017 07:31:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 07C79B8105A; Thu, 23 Feb 2017 07:31:35 -0800 (PST) To: d.frey@gmx.de, pbryan@anode.ca, mnot@mnot.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170223153135.07C79B8105A@rfc-editor.org> Date: Thu, 23 Feb 2017 07:31:35 -0800 (PST) Archived-At: Cc: aamelnikov@fastmail.fm, art@ietf.org, text/plain@rfc-editor.org, charset=UTF-8@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, iesg@ietf.org Subject: [art] [Errata Held for Document Update] RFC6902 (4787) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 15:31:36 -0000 The following errata report has been held for document update 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 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Daniel Frey Date Reported: 2016-08-25 Held by: Alexey Melnikov (IESG) 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. Mark Nottingham: This isn't an errata; it would require gaining consensus and updating the document. See also: https://github.com/json-patch/json-patch2 -------------------------------------- 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 nobody Tue Feb 28 01:27:58 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3302412706D; Tue, 28 Feb 2017 01:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 1bbhkdDN55N5; Tue, 28 Feb 2017 01:27:50 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 15CCC126FDC; Tue, 28 Feb 2017 01:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1S9Rk3I006510; Tue, 28 Feb 2017 10:27:46 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:f914:6d44:554a:662d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vXYC65SHrzDJ3B; Tue, 28 Feb 2017 10:27:46 +0100 (CET) From: Olaf Bergmann To: art@ietf.org, media-types@ietf.org Date: Tue, 28 Feb 2017 10:27:46 +0100 Message-ID: <87innupsvh.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Archived-At: Cc: core@ietf.org Subject: [art] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 09:27:52 -0000 --=-=-= Content-Type: text/plain Hi all, (core ML Cc'd due to specific interest in this topic) We have submitted an updated version of draft-shelby-exi-registration that documents appropriate use of the "+exi" structured syntax suffix. This document has been around since 2012 where it has been discussed in the IETF media-types mailing list. There has not been much progress since, specifically because the "application/exi" media type and the "exi" content coding deemed to be sufficient. Recent media type registration requests---in particular for application/senml+exi---indicate that there are cases where the generic exi media type and content coding header are not applicable. Any comments are welcome! Best regards Olaf --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: Received: from dspam.localhost by imap.informatik.uni-bremen.de (Dovecot) with LMTP id EZDaASJitFhdGAAACethxA for ; Mon, 27 Feb 2017 18:33:04 +0100 Return-Path: X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=6.2 tests=[DATE_IN_FUTURE_96_Q=2.896, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=disabled Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1RHWtU0003853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Feb 2017 18:33:01 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E81F12A2A1; Mon, 27 Feb 2017 09:32:55 -0800 (PST) From: internet-drafts@ietf.org To: "Carsten Bormann" , "Zach Shelby" , "Olaf Bergmann" Subject: New Version Notification for draft-shelby-exi-registration-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148821677512.21113.2713734803892289412.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 09:32:55 -0800 MIME-Version: 1.0 Content-Type: text/plain A new version of I-D, draft-shelby-exi-registration-02.txt has been successfully submitted by Olaf Bergmann and posted to the IETF repository. Name: draft-shelby-exi-registration Revision: 02 Title: The +exi Media Type Suffix Document date: 2017-02-22 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-shelby-exi-registration-02.txt Status: https://datatracker.ietf.org/doc/draft-shelby-exi-registration/ Htmlized: https://tools.ietf.org/html/draft-shelby-exi-registration-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-shelby-exi-registration-02 Abstract: Efficient XML Interchange (EXI) is an XML representation technique specified by the W3C to provide a time and space efficient encoding for XML documents. This document defines a new Structured Syntax Suffix "+exi" for use in a specific class of protocols, where "exi" content-type encoding or the generic "application/exi" media type are not applicable. 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. The IETF Secretariat --=-=-=-- From nobody Tue Feb 28 06:05:45 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B236A129502; Tue, 28 Feb 2017 06:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 HKF9XrJMueEA; Tue, 28 Feb 2017 06:05:41 -0800 (PST) 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 9CD5E129543; Tue, 28 Feb 2017 06:05:41 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBES7VSHNK00K72W@mauve.mrochek.com>; Tue, 28 Feb 2017 06:03:47 -0800 (PST) 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 <01QBDDVH6WZK0005AQ@mauve.mrochek.com>; Tue, 28 Feb 2017 06:03:45 -0800 (PST) Message-id: <01QBES7UHX6E0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 05:58:15 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 28 Feb 2017 10:27:46 +0100" <87innupsvh.fsf@aung.informatik.uni-bremen.de> References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> To: Olaf Bergmann Archived-At: Cc: media-types@ietf.org, art@ietf.org, core@ietf.org Subject: Re: [art] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:05:43 -0000 Has something changed about the definition of EXI that would make it actually appropriate as a media type suffix? Because unless there's been a change the reason this hasn't progressed is because it's inappropriate for it to do so. In particular, it isn't possible to process a type that ends in +exi in any significant way without knowing the type's schema. So unless there's a way of discovering that knowing nothing but the type name, +exi provides no utility. Ned > Hi all, > (core ML Cc'd due to specific interest in this topic) > We have submitted an updated version of draft-shelby-exi-registration > that documents appropriate use of the "+exi" structured syntax suffix. > This document has been around since 2012 where it has been discussed in > the IETF media-types mailing list. There has not been much progress > since, specifically because the "application/exi" media type and the > "exi" content coding deemed to be sufficient. > Recent media type registration requests---in particular for > application/senml+exi---indicate that there are cases where the generic > exi media type and content coding header are not applicable. > Any comments are welcome! > Best regards > Olaf From nobody Tue Feb 28 06:23:11 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA44A129563; Tue, 28 Feb 2017 06:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 PgNaS2ggHUpC; Tue, 28 Feb 2017 06:23:08 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 A119412958C; Tue, 28 Feb 2017 06:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1SEN5gF012219; Tue, 28 Feb 2017 15:23:05 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:f914:6d44:554a:662d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vXgls4XyJzDJCp; Tue, 28 Feb 2017 15:23:05 +0100 (CET) From: Olaf Bergmann To: Ned Freed References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> <01QBES7UHX6E0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 15:23:05 +0100 In-Reply-To: <01QBES7UHX6E0005AQ@mauve.mrochek.com> (Ned Freed's message of "Tue, 28 Feb 2017 05:58:15 -0800 (PST)") Message-ID: <87r32io0mu.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: media-types@ietf.org, art@ietf.org, core@ietf.org Subject: Re: [art] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:23:10 -0000 Hi Ned, Ned Freed writes: > Has something changed about the definition of EXI that would make it actu= ally > appropriate as a media type suffix? Because unless there's been a change = the > reason this hasn't progressed is because it's inappropriate for it to do = so. What has changed is the fact that +exi is in actual use. > In particular, it isn't possible to process a type that ends in +exi in a= ny > significant way without knowing the type's schema. So unless there's a way > of discovering that knowing nothing but the type name, +exi provides > no utility. Well, processing a document is one thing. But signaling that you can process a document (with or without schema) is another thing. The "+exi" suffix helps where application/exi and content-coding: exi are not applicable (e.g. in a CoAP Accept option). This is pretty much what the draft describes. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Feb 28 07:06:05 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAC1295B3; Tue, 28 Feb 2017 07:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 qsDZgOHDZELb; Tue, 28 Feb 2017 07:06:03 -0800 (PST) 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 E37A712953F; Tue, 28 Feb 2017 07:06:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBEUCWYHF4007NZV@mauve.mrochek.com>; Tue, 28 Feb 2017 07:05:07 -0800 (PST) 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 <01QBDDVH6WZK0005AQ@mauve.mrochek.com>; Tue, 28 Feb 2017 07:05:04 -0800 (PST) Message-id: <01QBEUCUSIQW0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 06:46:57 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 28 Feb 2017 15:23:05 +0100" <87r32io0mu.fsf@aung.informatik.uni-bremen.de> References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> <01QBES7UHX6E0005AQ@mauve.mrochek.com> <87r32io0mu.fsf@aung.informatik.uni-bremen.de> To: Olaf Bergmann Archived-At: Cc: media-types@ietf.org, art@ietf.org, Ned Freed , core@ietf.org Subject: Re: [art] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 15:06:04 -0000 > Hi Ned, > Ned Freed writes: > > Has something changed about the definition of EXI that would make it actually > > appropriate as a media type suffix? Because unless there's been a change the > > reason this hasn't progressed is because it's inappropriate for it to do so. > What has changed is the fact that +exi is in actual use. So are many other things that don't actually make sense. Usage doesn't make something valid to register. > > In particular, it isn't possible to process a type that ends in +exi in any > > significant way without knowing the type's schema. So unless there's a way > > of discovering that knowing nothing but the type name, +exi provides > > no utility. > Well, processing a document is one thing. But signaling that you can > process a document (with or without schema) is another thing. The "+exi" > suffix helps where application/exi and content-coding: exi are not > applicable (e.g. in a CoAP Accept option). This is pretty much what the > draft describes. Hmm. Well, if this assessment of the mechanism in CoAP is valid - and I take no position on that - it sounds to me like CoAP effectively extended the semantics of media types in a fairly fundamental way. In particular, it seems like you're using them as a signalling mechanism where no data of the given type is actually involved. If that's indeed the case, then that extension to the use of media types needs to be fully and completely described, along with its security considerations, so that types intended for this usage can undergo proper review before they are registered. There is some precedent for such usage, in that there are cases where the top-level name of a media type has been used for signalling, necessitating the registration of essentially the same type under audio/ and video/. But the type still functioned as a label for actual media. Anyway, IMO you have a lot of work to do before the registration of +exi can be justified. Ned From nobody Tue Feb 28 07:59:34 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30955129517; Tue, 28 Feb 2017 07:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 x-gk744KCyRs; Tue, 28 Feb 2017 07:59:28 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 08A5E1204D9; Tue, 28 Feb 2017 07:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1SFxOv2009231; Tue, 28 Feb 2017 16:59:24 +0100 (CET) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:30da:f914:6d44:554a:662d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vXjv04RLMzDJFt; Tue, 28 Feb 2017 16:59:24 +0100 (CET) From: Olaf Bergmann To: Ned Freed References: <87innupsvh.fsf@aung.informatik.uni-bremen.de> <01QBES7UHX6E0005AQ@mauve.mrochek.com> <87r32io0mu.fsf@aung.informatik.uni-bremen.de> <01QBEUCUSIQW0005AQ@mauve.mrochek.com> Date: Tue, 28 Feb 2017 16:59:24 +0100 In-Reply-To: <01QBEUCUSIQW0005AQ@mauve.mrochek.com> (Ned Freed's message of "Tue, 28 Feb 2017 06:46:57 -0800 (PST)") Message-ID: <87efyinw6b.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: media-types@ietf.org, art@ietf.org, core@ietf.org Subject: Re: [art] [media-types] [internet-drafts@ietf.org] New Version Notification for draft-shelby-exi-registration-02.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 15:59:29 -0000 Ned Freed writes: >> Well, processing a document is one thing. But signaling that you can >> process a document (with or without schema) is another thing. The "+exi" >> suffix helps where application/exi and content-coding: exi are not >> applicable (e.g. in a CoAP Accept option). This is pretty much what the >> draft describes. > > Hmm. Well, if this assessment of the mechanism in CoAP is valid - and I t= ake no > position on that - it sounds to me like CoAP effectively extended the sem= antics > of media types in a fairly fundamental way. I do not think it does, more likely was my description not accurate. What CoAP does is that it assigns a numeric value to a registered media type/content coding combination which then is used when negotiating the acceptable content type between sender and receiver. > In particular, it seems like you're using them as a signalling mechanism = where > no data of the given type is actually involved. If that's indeed the case= , then > that extension to the use of media types needs to be fully and completely > described, along with its security considerations, so that types intended > for this usage can undergo proper review before they are registered. The number is just an abbreviation of what would otherwise go into the Content-Type or Accept header together with Content-Coding. I do not see why this would be an extension to common handling of media types and their encodings? Gr=C3=BC=C3=9Fe Olaf From nobody Tue Feb 28 17:18:46 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00016129526; Tue, 28 Feb 2017 17:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvQQge0wV65u; Tue, 28 Feb 2017 17:18:39 -0800 (PST) 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 2AD75129873; Tue, 28 Feb 2017 17:18:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 23962B82107; Tue, 28 Feb 2017 17:18:22 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170301011822.23962B82107@rfc-editor.org> Date: Tue, 28 Feb 2017 17:18:22 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, art@ietf.org, rfc-editor@rfc-editor.org Subject: [art] STD 85, RFC 8098 on Message Disposition Notification X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:18:41 -0000 A new Request for Comments is now available in online RFC libraries. STD 85 RFC 8098 Title: Message Disposition Notification Author: T. Hansen, Ed., A. Melnikov, Ed. Status: Standards Track Stream: IETF Date: February 2017 Mailbox: tony@att.com, alexey.melnikov@isode.com Pages: 37 Characters: 80493 Obsoletes: RFC 3798 Updates: RFC 2046, RFC 3461 See Also: STD 85 I-D Tag: draft-ietf-appsawg-mdn-3798bis-16.txt URL: https://www.rfc-editor.org/info/rfc8098 DOI: 10.17487/RFC8098 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 are 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 multiprotocol 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 is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement). This document is a product of the ART Area General Application Working Group Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC