Although HTTP/= 2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP.

Thanks for the review.

> * For the bullet points in this document, some end in p= eriods and
> some don't.=C2=A0 I recommend the authors choose one and update<= /span>
> acco= rdingly.

Will update those without periods.

> * In section 1. "Introduction", the= last sentence is very clumsy.

&= gt; The Gen-ART review already points this out, and provides what I think
> is a = good suggested change.

It has been updated.

> * In section 4.4.2 "Establishing Interoperability&= quot;, the phrase
> "client
> would uses" should be "client uses"=

Will f= ix.

<= span style=3D"font-size:16px">> * In section 5.2 "Behavioral Change= s", the following sentence is

> difficult parse:

...
=C2=A0 =C2=A0> I think the = following has the same meaning:
>
> =C2=A0 "&= quot;"
> =C2=A0 One class of behavior change involves changes in the set of = errors
&g= t; =C2=A0 to be returned when various failure conditions occur.
> =C2=A0 "&q= uot;"
>
> That's not tremendously better,= but I think it's a little easier to
> wrap one's mind around.

Will change.

> * In the title for Section 9.3 "XDR Corrections t= o REQUIRED
> features",
> "Features" should be capitalized.

Will fix.

> * In Section 9.3 "XDR Corrections to REQUIRED features&quo= t;, the word
> "correct" should be "corrected" in the sentenc= e "Such clients would
> only
> be capable of interoperating with servers that su= pported the correct
> version."

Will fix.

On = Fri, May 12, 2017 at 4:37 PM, Matthew Miller <linuxwolf+iet= f@outer-planes.net> wrote:

= Reviewer: Matthew Miller
Review result: Ready with Issues

Document: draft-ietf-nfsv4-versioning-09
IETF LC End Date: 2017-05-12
IESG Telechat date: 2017-05-25

This document provides guidance for dealing with extensions
and versioning in NFSv4, including how and when to update
minor versions.

This document is mostly ready.=C2=A0 Some of the grammatical choices
make for a more difficult read; the most obvious ones to me are
nits below.

Major issues:

NONE

Minor issues:

NONE

Nits/editorial comments:

* For the bullet points in this document, some end in periods and
some don't.=C2=A0 I recommend the authors choose one and update
accordingly.

* In section 1. "Introduction", the last sentence is very clumsy.=
The Gen-ART review already points this out, and provides what I think
is a good suggested change.

* In section 4.4.2 "Establishing Interoperability", the phrase "client
would uses" should be "client uses"

* In section 5.2 "Behavioral Changes", the following sentence is<= br> difficult parse:

=C2=A0 =C2=A0"""
=C2=A0 =C2=A0One class of behavioral change involves changes in the set of<= br> errors
=C2=A0 =C2=A0to be returned in the event of various errors.
=C2=A0 =C2=A0"""

I think the following has the same meaning:

=C2=A0 =C2=A0"""
=C2=A0 =C2=A0One class of behavior change involves changes in the set of er= rors
=C2=A0 =C2=A0to be returned when various failure conditions occur.
=C2=A0 =C2=A0"""

That's not tremendously better, but I think it's a little easier to=
wrap one's mind around.

* In the title for Section 9.3 "XDR Corrections to REQUIRED
features",
"Features" should be capitalized.

* In Section 9.3 "XDR Corrections to REQUIRED features", the word=
"correct" should be "corrected" in the sentence "S= uch clients would
only
be capable of interoperating with servers that supported the correct
version."

--001a114417aa052965054f67c626-- From nobody Sun May 14 07:24: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 4618812932A; Sun, 14 May 2017 07:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 WDFZQ9KGF3LD; Sun, 14 May 2017 07:24:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 79F961201FA; Sun, 14 May 2017 07:23:57 -0700 (PDT) Received: from [192.168.178.20] ([93.217.100.51]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M8eAd-1dxDjM0yvL-00wB2G; Sun, 14 May 2017 16:23:55 +0200 To: IETF Discussion , art@ietf.org From: Julian Reschke Message-ID: Date: Sun, 14 May 2017 16:23:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:q1Dk5fbzBRKSa9CB+rFw6/JTwk9Td0BAfmilJFWL9t0cQG4wHhQ M2uOx/6K+uglFCdsSehCJlH/DbScGIQzuJ02GFSDME7GURy7GGFYnTMORio+UoegdupLieJ PWOP5gunn5l0pg7oB7UJnUldjxVcSyjSjFF3R34wZ6j6wy6vdWGoenWVJgaKb3iZTZKe5zv MAjwQUbqlA8j0Pdmyb0Zw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Mz0PWO78b0g=:0uvJQyjeK6lyx65QF3x9gl BOhjR7pNQOUlJ5lhj7aBHdaTvv8m8sqotLS2hKNrMhjtu8leeBlBxOJzcXnUNdmKByCx7FLsb 6xaXJWukjylIn5fp7H3qaELAaknOKeg1JgmsRHVVxMe5PkNibsOPXtMXkt/rZmBGEoWweQjc4 XgnbDwtcSTTh/52NyPMSBWEmeqcL+5pOKdPCo8zfY9ersQSdgrP/EbnrqwSL8NMAWoPPEgkH3 VN9jsZno4uM5U67OulUWzWmyJEOMuH6Bo5XVGEZEkkcRS3ywwHNdi3pPg19xbzxq2I9UhvnKv et5VkE1V1eEEmLFffJlmIRVOty2BJOuIhke1lW0siHi0POBiu7ByLQ2L/xAtPeoUB/1++P/iJ fWpJy1tJMSqemxgkMF2wDlRh6VDEHEUZzkjNF5Z+qqrSl5V/6Nl2IvXUP3HVisIuZmLrJaLO+ T/vS9303LK9mW9TFMcZW1Pz5ooKJ8QHbrMg5DTCpN7PGi1ByzLgJkvlMabAWqar2JKaL1/PDe pED2HF7hv828e1Wjo1T4G8oTyvSdzrtHsoxFw64J4kxY2MtsUCq+00s3v8xJNi3knirMPC1cb W3022/gsOgLF76bAgm6E8+SjFkCO2yooc0ui97h8mLRTtUAQ2WRXyumYQTnPwUMs2ebNuu+kk 0j0IRjKANIX1QB534edHfk26JrRCsl5KyaZn2/jfDsYonhnh9zOWadduBSxhkkmrbgG4R0a3x QTuSgrFgHFufUOhhuAvBJOs7y1rOqMjjGn/rI91GTSc7v+lJxBG14gngJKGhoQ3+09qQWo6Ow DOy/R2X Archived-At: Subject: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 14:24:44 -0000 Reviewer: Julian Reschke Review result: Not Ready Document: draft-ietf-calext-caldav-attachments-02 IETF LC End Date: 2017-05-14 IESG Telechat date: 2017-05-25 This document describes attachment handling in CalDAV (WebDAV based calendaring). The mechanism described by this document is essential RPCish, using HTTP POST for tunneling. It will work in practice, but it definitively isn't state of the art in IETF protocols, in particular in an otherwise WebDAV/CalDAV-based ecosystem. Major issues: The main issue with this specification is that it 1) models operations on attachments as POST operations, where the actual type of operation is specified using a query parameter, instead of using the HTTP methods POST, PUT, and DELETE. 2) hardwires specific query strings into the protocol, violating a MUST level requirement in BCP 190 (see https://tools.ietf.org/html/rfc7320#section-2.4): Applications MUST NOT directly specify the syntax of queries, as this can cause operational difficulties for deployments that do not support a particular form of a query. For example, a site may wish to support an application using "static" files that do not support query parameters. Re 1) this is even called out specifically in Sections 3.8 (update) and 3.9 (remove), but it's not clear at all why that is the case. Re 2) Part of the hard-wiring could be avoided by using different HTTP methods for the different actions. The other parameters could be made discoverable using URIs / URI templates, exposed as WebDAV properties, as is the case in RFC 5995. 5.1. Cal-Managed-ID Response Header Field This doesn't seem to address the points listed in (and it wouldn't be needed if the attachment would be modeled as an HTTP resource whose values could be reported back in a Location header field upon creation). Minor issues: 3.12.4. Processing Time Clients can expect servers to take a while to respond to POST requests that include large attachment bodies. Servers SHOULD use the "102 (Processing)" interim response defined in Section 10.1 of [RFC2518] to keep the client connection alive if the POST request will take significant time to complete. While discussing the new code 103 in the HTTP WG, we considered interop problems with existing code that doesn't handle 1xx status codes at all, or had problems with status codes other than 100. I personally support use of new 1xx status codes, but it would be good to hear whether the WG considered deployment problems when making this a SHOULD-level requirement. 3.12.5. Automatic Clean-up by servers Servers MAY automatically remove attachment data, for example to regain the storage taken by unused attachments, or as the result of a virus scanning. When doing so they SHOULD NOT modify calendar data referencing those attachments. Instead they SHOULD respond with "410 (Gone)" to any request on the removed attachment URI. This essentially requires servers to distinguish between resources that never have been there, and those which have been there but were removed. It's definitively additional work for the server, where it's not clear what the benefit for clients is. 6.1. CALDAV:managed-attachments-server-URL property This mechanism is really funky. Depending on the presence of this property, the authority part of attachment URIs is rewritten or not. Depending on its contents, the rewrite is based on yet another default or the given value. It's not clear why all this can't be replaced by a mechanism where attachment URIs can be relative references to be resolved against a base URI. Nits/editorial comments: In addition, such a server MUST support the "return=representation" Prefer header field value [RFC7240] on successful HTTP PUT and POST requests targeting existing calendar object resources, by returning the new representation of that calendar resource (including its new ETag header field value) in the response. (not specific to this spec, but to the CalDAV ecosystem: the specs rely a lot on DAV feature names, but there's no registry - I believe it would be good if we added one in a separate spec) 1. Introduction The iCalendar [RFC5545] data format is used to represent calendar data and is used with iTIP [RFC5546] to handle scheduling operations between calendar users. [RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP [RFC7230], for accessing calendar data stored on a server. Maybe also mention RFC 4918 here. RFC 4918 currently isn't referenced at all, despite the fact that the specification relies on stuff defined over there, such as the "DAV" response header field. From nobody Mon May 15 07:09:33 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 E4C01129AEB; Mon, 15 May 2017 07:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 o1iAHhScTzlE; Mon, 15 May 2017 07:09:20 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) (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 54C7912EAB9; Mon, 15 May 2017 07:03:31 -0700 (PDT) Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v4FE3P6L032523 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2017 10:03:26 -0400 To: Julian Reschke , IETF Discussion , art@ietf.org References: From: Ken Murchison Organization: Carnegie Mellon University Message-ID: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu> Date: Mon, 15 May 2017 10:03:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.5.15.135416 X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0) X-SMTP-Spam-Score: 33% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.202 Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 15 May 2017 14:09:23 -0000 Hi Julian, Thanks for the review. Comments inline. On 05/14/2017 10:23 AM, Julian Reschke wrote: > Reviewer: Julian Reschke > Review result: Not Ready > > Document: draft-ietf-calext-caldav-attachments-02 > IETF LC End Date: 2017-05-14 > IESG Telechat date: 2017-05-25 > > This document describes attachment handling in CalDAV (WebDAV based > calendaring). > > The mechanism described by this document is essential RPCish, using > HTTP POST for tunneling. It will work in practice, but it definitively > isn't state of the art in IETF protocols, in particular in an > otherwise WebDAV/CalDAV-based ecosystem. > > Major issues: > > The main issue with this specification is that it > > 1) models operations on attachments as POST operations, where the > actual type of operation is specified using a query parameter, instead > of using the HTTP methods POST, PUT, and DELETE. The resource being acted upon is an actual calendar resource, which is already in place. The attachments are meta-data associated with one or more calendar resources, which is why a POST is used on the calendar resource to manipulate an attachment. Can you explain how you would envision different HTTP methods be used to add/update/delete an attachment associated with a calendar resource? > 2) hardwires specific query strings into the protocol, violating a > MUST level requirement in BCP 190 (see > https://tools.ietf.org/html/rfc7320#section-2.4): > > Applications MUST NOT directly specify the syntax of queries, as this > can cause operational difficulties for deployments that do not > support a particular form of a query. For example, a site may wish > to support an application using "static" files that do not support > query parameters. Which part(s) of the query syntax MUST not be specified? The entire thing? Just the keywords? Did RFC 7808 get this wrong, or is URI templating ok? > Re 1) this is even called out specifically in Sections 3.8 (update) > and 3.9 (remove), but it's not clear at all why that is the case. > > Re 2) Part of the hard-wiring could be avoided by using different HTTP > methods for the different actions. The other parameters could be made > discoverable using URIs / URI templates, exposed as WebDAV properties, > as is the case in RFC 5995. As above, can you explain how different HTTP methods would be used where the target of the add/update/remove operation is an existing calendar resource? > 5.1. Cal-Managed-ID Response Header Field > > This doesn't seem to address the points listed in > > (and it wouldn't be needed if the attachment would be modeled as an > HTTP resource whose values could be reported back in a Location header > field upon creation). Can parameters be added to a Location header field (it doesn't appear so), or are you suggesting that the managed-id value be encoded in the URI-reference value? > > Minor issues: > > 3.12.4. Processing Time > > Clients can expect servers to take a while to respond to POST > requests that include large attachment bodies. Servers SHOULD use > the "102 (Processing)" interim response defined in Section 10.1 of > [RFC2518] to keep the client connection alive if the POST request > will take significant time to complete. > > While discussing the new code 103 in the HTTP WG, we considered > interop problems with existing code that doesn't handle 1xx status > codes at all, or had problems with status codes other than 100. I > personally support use of new 1xx status codes, but it would be good > to hear whether the WG considered deployment problems when making this > a SHOULD-level requirement. Existing implementations of this CalDAV extension all seem to handle 1xx status codes. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Mon May 15 09:09:48 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 E41AE12EAC6; Mon, 15 May 2017 09:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 2dcfzZW0ltGn; Mon, 15 May 2017 09:09:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 73EAE12EAC1; Mon, 15 May 2017 09:04:42 -0700 (PDT) Received: from [192.168.178.20] ([93.217.120.200]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MSdRI-1dblX92eSC-00RbhZ; Mon, 15 May 2017 18:04:31 +0200 To: Ken Murchison , IETF Discussion , art@ietf.org References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu> From: Julian Reschke Message-ID: Date: Mon, 15 May 2017 18:04:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:n/iUtHBhmkiQmU1oJS98CwbDX2IFXcMEh6e8+EZw0cb9BF/Ju11 p/y29Nt+LgQ+IMW/gmKmxmoxv2m2J/7PRv1Nmx8SzYUkShqN1JimVJn1WFcLHssYktmQGGc BweUazeMCw+67lKi+jmTFMZ3SOMqXBVEb7zswu650wCRrBK3V41OJv4hNVNJffWmuOvCFkv BzizMnmh4V8bTqx+LtW3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:49s4ZXwvPek=:ffhbn/sr94+FoQ7xDhqIpr cgYMLiCv6ldpDaREMpxTOx/HBFWFf3u4GM586eCq30c4m8tnuRlsje0nY+9MiELFhVbIp51H1 WPE2uwMLXcg4mE6oUgA8IpoxKRc4bkYcwOciAagmHPoMqFj/x7kpTBeI2c2viLOj5N3r/eqHc U3k5qkVByBGNZzYZIQ+2k/KTKjv3b5nKzQS9ALY4nM7TAkxk/kpLF2pPecmnT1uU4tRNXfpze r7dEOL/lfyT84phuLh0kWbAlB7lc+Jxo1qnBtZT2S338ej+twpuiP8Em5AYSPzgveogFwoooW vBLbxqfHjvGZ/o55EoP6TSPxenYYWID75qQzOQYUCfTWU6dv6FLozQrMztfkYWYwBmtlVhPuw qVH8RIVJdlMtUkcsa5ok3YQQ5DfgVYWF6vLgCEmdZn2cl3WOr8p8d6GosdpAi3PWJnqAnHS9J EHYC9IKdO2TgyjfL2DlMmCnE4BR+ttf5O/S6UbEtOZvCx27bIOvEbmb4wXAy8Zc4tr65DolrJ rBAObbjkzKKgvwRjnFpNlI9J4WUmGuN+dysA27aI/hU8ET3ytvb2tjsiYrwci3CVG/03Z0yTv CxP4xt+lhRkabMhdEev+uIXCyUSsoc7ulwxYvCKueHpgxYwPrNWxcwXOLW0g66PUCG0I+FSIf j+mCZ37luMK3URH9HLF8p8K+/aPbFZLmK72Tww/YcDBmE988/OK0s+XfMR5c4/iLobmYpLc+3 PjRdtrna3BBuJsu2JlAjPHDPWMjckpp55USlSc0k9EiNU2mecFq+hePij1ML5wgwik0GtTv2N M6V4bJ4 Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 15 May 2017 16:09:41 -0000 On 2017-05-15 16:03, Ken Murchison wrote: > Hi Julian, > > Thanks for the review. Comments inline. > > > On 05/14/2017 10:23 AM, Julian Reschke wrote: >> Reviewer: Julian Reschke >> Review result: Not Ready >> >> Document: draft-ietf-calext-caldav-attachments-02 >> IETF LC End Date: 2017-05-14 >> IESG Telechat date: 2017-05-25 >> >> This document describes attachment handling in CalDAV (WebDAV based >> calendaring). >> >> The mechanism described by this document is essential RPCish, using >> HTTP POST for tunneling. It will work in practice, but it definitively >> isn't state of the art in IETF protocols, in particular in an >> otherwise WebDAV/CalDAV-based ecosystem. >> >> Major issues: >> >> The main issue with this specification is that it >> >> 1) models operations on attachments as POST operations, where the >> actual type of operation is specified using a query parameter, instead >> of using the HTTP methods POST, PUT, and DELETE. > > The resource being acted upon is an actual calendar resource, which is > already in place. The attachments are meta-data associated with one or Only for creation of the attachment. Once is has been created, it should have its own URI, and the usual HTTP methods should be applicable. > more calendar resources, which is why a POST is used on the calendar > resource to manipulate an attachment. Can you explain how you would > envision different HTTP methods be used to add/update/delete an > attachment associated with a calendar resource? For adding, I would define an HTTP resource that can be posted to. It could be discovered through a WebDAV property. >> 2) hardwires specific query strings into the protocol, violating a >> MUST level requirement in BCP 190 (see >> https://tools.ietf.org/html/rfc7320#section-2.4): >> >> Applications MUST NOT directly specify the syntax of queries, as this >> can cause operational difficulties for deployments that do not >> support a particular form of a query. For example, a site may wish >> to support an application using "static" files that do not support >> query parameters. > > Which part(s) of the query syntax MUST not be specified? The entire > thing? Just the keywords? Did RFC 7808 get this wrong, or is URI > templating ok? I'm not familiar with 7808. URI templates are superior than hardwiring everything for sure. We just shouldn't enforce specific URI templates - the server should be able to specify them, clients would need to discover them. >> Re 1) this is even called out specifically in Sections 3.8 (update) >> and 3.9 (remove), but it's not clear at all why that is the case. >> >> Re 2) Part of the hard-wiring could be avoided by using different HTTP >> methods for the different actions. The other parameters could be made >> discoverable using URIs / URI templates, exposed as WebDAV properties, >> as is the case in RFC 5995. > > As above, can you explain how different HTTP methods would be used where > the target of the add/update/remove operation is an existing calendar > resource? > ... (see above) >> 5.1. Cal-Managed-ID Response Header Field >> >> This doesn't seem to address the points listed in >> >> (and it wouldn't be needed if the attachment would be modeled as an >> HTTP resource whose values could be reported back in a Location header >> field upon creation). > > Can parameters be added to a Location header field (it doesn't appear > so), or are you suggesting that the managed-id value be encoded in the > URI-reference value? I suggest that the attachment *is* a HTTP resource, thus has it's own URI. >> Minor issues: >> >> 3.12.4. Processing Time >> >> Clients can expect servers to take a while to respond to POST >> requests that include large attachment bodies. Servers SHOULD use >> the "102 (Processing)" interim response defined in Section 10.1 of >> [RFC2518] to keep the client connection alive if the POST request >> will take significant time to complete. >> >> While discussing the new code 103 in the HTTP WG, we considered >> interop problems with existing code that doesn't handle 1xx status >> codes at all, or had problems with status codes other than 100. I >> personally support use of new 1xx status codes, but it would be good >> to hear whether the WG considered deployment problems when making this >> a SHOULD-level requirement. > > Existing implementations of this CalDAV extension all seem to handle 1xx > status codes. I'm more concerned about HTTP libraries and intermediaries. See, for instance, . Best regards, Julian From nobody Wed May 17 06:07:18 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 31EF012EB53; Wed, 17 May 2017 06:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Ymnj9aZWULZR; Wed, 17 May 2017 06:07:07 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) (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 775791294B7; Wed, 17 May 2017 06:07:07 -0700 (PDT) Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v4HD723i019793 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 May 2017 09:07:03 -0400 To: Julian Reschke , IETF Discussion , art@ietf.org References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu> From: Ken Murchison Organization: Carnegie Mellon University Message-ID: Date: Wed, 17 May 2017 09:07:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.5.17.125716 X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0) X-SMTP-Spam-Score: 33% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.202 Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 17 May 2017 13:07:09 -0000 On 05/15/2017 12:04 PM, Julian Reschke wrote: > On 2017-05-15 16:03, Ken Murchison wrote: >> Hi Julian, >> >> Thanks for the review. Comments inline. >> >> >> On 05/14/2017 10:23 AM, Julian Reschke wrote: >>> Reviewer: Julian Reschke >>> Review result: Not Ready >>> >>> Document: draft-ietf-calext-caldav-attachments-02 >>> IETF LC End Date: 2017-05-14 >>> IESG Telechat date: 2017-05-25 >>> >>> This document describes attachment handling in CalDAV (WebDAV based >>> calendaring). >>> >>> The mechanism described by this document is essential RPCish, using >>> HTTP POST for tunneling. It will work in practice, but it definitively >>> isn't state of the art in IETF protocols, in particular in an >>> otherwise WebDAV/CalDAV-based ecosystem. >>> >>> Major issues: >>> >>> The main issue with this specification is that it >>> >>> 1) models operations on attachments as POST operations, where the >>> actual type of operation is specified using a query parameter, instead >>> of using the HTTP methods POST, PUT, and DELETE. >> >> The resource being acted upon is an actual calendar resource, which is >> already in place. The attachments are meta-data associated with one or > > Only for creation of the attachment. Once is has been created, it > should have its own URI, and the usual HTTP methods should be applicable. Using HTTP methods directly on the attachment URI makes things more difficult because the calendar resource(s) referencing the attachment also need to be updated. This would have to be done either as a side-effect of the PUT/DELETE on the attachment, or as a separate PUT (and separate round-trips) on the resource(s). The desire was to avoid doing either one of these, which is why a POST on the calendar resource was chosen as the method to add/update/delete an attachment from a calendar resource. >> more calendar resources, which is why a POST is used on the calendar >> resource to manipulate an attachment. Can you explain how you would >> envision different HTTP methods be used to add/update/delete an >> attachment associated with a calendar resource? > > For adding, I would define an HTTP resource that can be posted to. It > could be discovered through a WebDAV property. We could certainly define a template or series of templates for add/update/delete and expose them as WebDAV properties. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed May 17 06:57:39 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 5423412EB33; Wed, 17 May 2017 06:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 M6VyhUatB5Be; Wed, 17 May 2017 06:57:28 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (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 08D2012EC7A; Wed, 17 May 2017 06:51:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id F0B4C6D53789; Wed, 17 May 2017 09:51:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QOO5RxFFuiv; Wed, 17 May 2017 09:51:21 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id C0D276D5377E; Wed, 17 May 2017 09:51:20 -0400 (EDT) Date: Wed, 17 May 2017 09:51:19 -0400 From: Cyrus Daboo To: Ken Murchison , Julian Reschke , IETF Discussion , art@ietf.org Message-ID: <5A6C244B4A6B876F82606F31@caldav.corp.apple.com> In-Reply-To: References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu>

X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=625 Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 17 May 2017 13:57:31 -0000 Hi Ken, --On May 17, 2017 at 9:07:02 AM -0400 Ken Murchison wrote: >> For adding, I would define an HTTP resource that can be posted to. It >> could be discovered through a WebDAV property. > > We could certainly define a template or series of templates for > add/update/delete and expose them as WebDAV properties. > I would be OK with adding that, provided we also include an Appendix that describes what currently shipping implementations do - basically what is coded into the current spec. i.e., the template allows the same form of query param based URIs as we have today. -- Cyrus Daboo From nobody Wed May 17 06:59:56 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 528C5129BCE; Wed, 17 May 2017 06:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ZgetMk6RsFwh; Wed, 17 May 2017 06:59:52 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (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 D9FB3128656; Wed, 17 May 2017 06:53:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 210C86D53811; Wed, 17 May 2017 09:53:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBeP1xenGJ55; Wed, 17 May 2017 09:53:46 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 1D9ED6D53802; Wed, 17 May 2017 09:53:46 -0400 (EDT) Date: Wed, 17 May 2017 09:53:44 -0400 From: Cyrus Daboo To: Ken Murchison , Julian Reschke , IETF Discussion , art@ietf.org Message-ID: In-Reply-To: References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu>

X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1174 Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 17 May 2017 13:59:54 -0000 Hi Ken, --On May 17, 2017 at 9:07:02 AM -0400 Ken Murchison wrote: >> Only for creation of the attachment. Once is has been created, it >> should have its own URI, and the usual HTTP methods should be applicable. > > Using HTTP methods directly on the attachment URI makes things more > difficult because the calendar resource(s) referencing the attachment > also need to be updated. This would have to be done either as a > side-effect of the PUT/DELETE on the attachment, or as a separate PUT > (and separate round-trips) on the resource(s). The desire was to avoid > doing either one of these, which is why a POST on the calendar resource > was chosen as the method to add/update/delete an attachment from a > calendar resource. One tricky aspect here is that calendar servers may not "host" the attachments themselves - i.e., they could use a separate "drop box" service to store the resources. In that case it is important that changes to the attachments are always managed through the calendar server so that it can alert clients via changes to the calendar data whenever an attachment is added, changed, or removed. -- Cyrus Daboo From nobody Wed May 17 07:06:17 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 73034129418; Wed, 17 May 2017 07:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 dJEDtbprdtcT; Wed, 17 May 2017 07:06:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 ADD96124281; Wed, 17 May 2017 06:58:10 -0700 (PDT) Received: from [192.168.178.20] ([93.217.117.158]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lwoiq-1e45352cEC-016RvB; Wed, 17 May 2017 15:58:03 +0200 To: Ken Murchison , IETF Discussion , art@ietf.org References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu>

From: Julian Reschke Message-ID: <7bcfecea-3a89-978c-9e1b-edf9aac5dd44@gmx.de> Date: Wed, 17 May 2017 15:58:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:w6GTVvb1P50+BbhIgQc9idkKIq+GaHaSg7av9cY3+/lIykUj/2r vXNsT7+0USymC6z4xGuP+9snrxaev3FiyA/eKrJyUHXHzuqCugmYrFxi08DWTrJ/U6jEPB2 u3u26aS9wxwswMatDAu92s0hvQirex94q+e8OY1CPwX+KAcm/g6GdTunouvsykum/cAIhOL JQ0EVyS67AR9BQdO+OVrQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:MwWTpvXgYYw=:Kc50tQ9aKrXyRdwtW3e/h6 jZsn92p8Z6fzFDp+7sKGlbPeObFlMBANDJkmcpidDi/t6/btSuIi5+mJUt27rx/ns77p1/20p gN38NqrT00rJ0A24PZ1Y20wZklygbd7erjPtsBROrVCDON46hv3WJZXteN2CprgS47EGKI+cA nrYKuPpLbXh+1UyyzO3emTbEZZ6UF3licBSp8BiSubxlcQbszaAFJ6wViLrGm3Ev2GF5S102T ni+5Qi2XmsVTo3sIL22qSMmqAsXoAj9ZvO34C3bqs0AQX+HNsA4jeS8CCKMm6ToYcAR+8hRtt 131bn1kDpiSU7LBkkfH8doSqZV9WFNLG2FbFt7RyUjwj21fbLqkdZFR7ZE9bwAjokqODXKIN1 66iUpsqBKeJ8D7c6/V5J2/fU5YPEjBvlCcIMA5voBo29PcJrbtYEFkqvsj2B+rgsYj0TVJhe4 axcXwqWpBzhvCv3Kf009c0A7H0rw0nu0Byfcc0qfSd1GzJV4TtJyVi86GlvW4JQTbTVKXDzvF edeRXipijKtwG4cORkKTk7zotHn1tGepzxOaTymoOb7V+59eQnZoCevy4XjZ9u43w/tl3jllj tuRZgDOmFZxR3c0BstU1E7EQG89fYaop3W7X2A48/11PuYxE6QoAXcmnOX2pFrJghkHcYfv8o vhvfvcmW9yDv+CxcyXixWCC9BMGjfZxyi2+74vUvt3NjUAEle0ceg7KkgikjiGf9HqY+ZPYDU JYYOzxsTRIcY6c3DGof2M2YrVVLfPY//xxYehSnwSCt9r4A5lwXpNjwsUX2m0IG3JuEOPlM2w 9h1dvWn Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 17 May 2017 14:06:08 -0000 On 2017-05-17 15:07, Ken Murchison wrote: > ... >> Only for creation of the attachment. Once is has been created, it >> should have its own URI, and the usual HTTP methods should be applicable. > > Using HTTP methods directly on the attachment URI makes things more > difficult because the calendar resource(s) referencing the attachment > also need to be updated. This would have to be done either as a > side-effect of the PUT/DELETE on the attachment, or as a separate PUT > (and separate round-trips) on the resource(s). The desire was to avoid > doing either one of these, which is why a POST on the calendar resource > was chosen as the method to add/update/delete an attachment from a > calendar resource. But the POST is *not* on the calendar resource, but on the calendar resource + query parameters, which, from HTTP's point of view is a different resource already. Furthermore, what URIs are used is orthogonal to the question of which methods to use. Why is POST /calendar-entry?action=remove&attachment=xyz easier to process than DELETE /calendar-entry?attachment=xyz or DELETE /calendar-entry/attachments/xyz ? > ... Best regards, Julian From nobody Wed May 17 07:10:12 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 2C84F129537; Wed, 17 May 2017 07:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 yrdb2EgAro7M; Wed, 17 May 2017 07:10:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 4D7EB12EBBD; Wed, 17 May 2017 07:01:45 -0700 (PDT) Received: from [192.168.178.20] ([93.217.117.158]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MXZw6-1dWNjz11hG-00WY5i; Wed, 17 May 2017 16:01:29 +0200 To: Cyrus Daboo , Ken Murchison , IETF Discussion , art@ietf.org References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu>

From: Julian Reschke Message-ID: Date: Wed, 17 May 2017 16:01:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.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:Sk8ZU+ZN4nmfIWLo8PmVmC++wsVKMHckaY/9IhmOWsdaXzGtl5L nKsg7bre4vuobywgm9lr+nNZFbIa2k2JGi/1y0aO+ZYmXc0iIZoObXbjtbozdMpB+mqyD3x m8sPu7Ne0grghandgNz+YgplMJLQ85xqrz8IFz6Y4Y2wu199yOF7dED7HDaC3F/k7I0N3zy AYLfWDkX89lPBpwRvmWOQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0G5DnqNmknM=:g6DXoFbtgjidE+tbRerKYd DENIAuq8rQeJ/1XuoNhVtvTi4o4RH5tGfxaLJ8q83ju93T+x5LKZWfNEm5fScOcdKbzyqJLgX YMvh8mFUsSvYUDehT4PrnFBWl7WaLKrY/7VypOVraF5QmWI3BF24B4R73ona5MxG9uxY06Ri8 pMFKIgpEDjgM+dK74Af2zen2zc5+7gcy/IdJEu7v03d9CbyjwdpmGNScesiXL8Dp9d+8hcdub MyolTjoqpj0icSRCd8CupMByYldWwqA6CVZ73LHhNKuSatH0L0Q8KfeHmFPiS2Dna9aa+bgxw XmkgSi4p91CKqvs9sL/bZyWNxEnNj5/4UbXsVQqDnB6UvN7leqR0KyBSJ/ILZD2HsxvPXkNyA sFjQLIthVx9+x6CSksKEqSphWCCohGFUZ7/vuno4pReZ7qR+DWaEKf2rEsepyABVTbnrO39og JxaEkFyvvhToaVbaBFPr1l5a0yravgwG1U4ytX319OnpE4CinyXAhYeKjbJ6w1Am2y4rtQSHN K+OU+Lsb8HLFtZuOmSt86tCUoC8a5RA7MI7g3AJOJDzAeFbrkd0ZMPKYtztGwrEK4dyiIJFsH 5otV0x5kwQNLxaArWV9tZ3Jc5c1XesQxbgCRM98dKppDNUa37AHo1xAAaNCl3tHwfO4UZATbY oqO3d+mDynV0yEn4QF7a2eeDtIHaHfOXU9i2so5eMB9QMr0UEUg1fhOepni98uWG8dRn1t9rT GVvgiZKfNSsXJFk/Yr1lMjVPoLOLsGwGMp5hVAwsvIwQ8I83TnjxxDukszmsF8XCJ/hpDnveD bCFeKq3 Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 17 May 2017 14:10:11 -0000 On 2017-05-17 15:53, Cyrus Daboo wrote: >> Using HTTP methods directly on the attachment URI makes things more >> difficult because the calendar resource(s) referencing the attachment >> also need to be updated. This would have to be done either as a >> side-effect of the PUT/DELETE on the attachment, or as a separate PUT >> (and separate round-trips) on the resource(s). The desire was to avoid >> doing either one of these, which is why a POST on the calendar resource >> was chosen as the method to add/update/delete an attachment from a >> calendar resource. > > One tricky aspect here is that calendar servers may not "host" the > attachments themselves - i.e., they could use a separate "drop box" > service to store the resources. In that case it is important that > changes to the attachments are always managed through the calendar > server so that it can alert clients via changes to the calendar data > whenever an attachment is added, changed, or removed. Again, that's an implementation detail. Just because the calendar server stores attachments somewhere else doesn't mean it has to expose those URIs. Best regards, Julian From nobody Mon May 22 11:59:33 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 2CFB712878D; Mon, 22 May 2017 11:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 UpilocMj7ZWp; Mon, 22 May 2017 11:59:22 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) (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 985AB126C2F; Mon, 22 May 2017 11:59:22 -0700 (PDT) Received: from [172.31.24.242] (VPN-172-31-24-242.VPN.CMU.LOCAL [172.31.24.242]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v4MIx7xR050219 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 May 2017 14:59:08 -0400 To: Julian Reschke , IETF Discussion , art@ietf.org References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu>

<7bcfecea-3a89-978c-9e1b-edf9aac5dd44@gmx.de> From: Ken Murchison Organization: Carnegie Mellon University Cc: Cyrus Daboo Message-ID: <07f64bc5-13f6-62a0-3c04-91c780f69672@andrew.cmu.edu> Date: Mon, 22 May 2017 14:59:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <7bcfecea-3a89-978c-9e1b-edf9aac5dd44@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.5.22.185116 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.202 Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 22 May 2017 18:59:24 -0000 On 05/17/2017 09:58 AM, Julian Reschke wrote: > On 2017-05-17 15:07, Ken Murchison wrote: >> ... >>> Only for creation of the attachment. Once is has been created, it >>> should have its own URI, and the usual HTTP methods should be >>> applicable. >> >> Using HTTP methods directly on the attachment URI makes things more >> difficult because the calendar resource(s) referencing the attachment >> also need to be updated. This would have to be done either as a >> side-effect of the PUT/DELETE on the attachment, or as a separate PUT >> (and separate round-trips) on the resource(s). The desire was to avoid >> doing either one of these, which is why a POST on the calendar resource >> was chosen as the method to add/update/delete an attachment from a >> calendar resource. > > But the POST is *not* on the calendar resource, but on the calendar > resource + query parameters, which, from HTTP's point of view is a > different resource already. > > Furthermore, what URIs are used is orthogonal to the question of which > methods to use. > > Why is > > POST /calendar-entry?action=remove&attachment=xyz > > easier to process than > > DELETE /calendar-entry?attachment=xyz > > or > > DELETE /calendar-entry/attachments/xyz > > ? The issue here is that a single calendar resource may contain multiple events (recurring event with overrides) and a particular attachment may be associated with more than one instance of that event. For this reason, we felt it best to use the calendar resource as the gateway to the attachments, thus allowing manipulating multiple instances of an attachment in a single round-trip. Also, by preventing clients from manipulating attachments directly, a CalDAV server isn't forced to alter all calendar resources associated with a particular attachment. We also have a fairly large number of deployed implementations which we do not want to make non-compliant by substantially modifying the protocol. At this point, specifying the use of HTTP methods other than POST would indeed make existing implementations non-compliant. We would definitely like to make this protocol conform to current HTTP practice where possible, and would also document where we have strayed from existing practice if required to do so. Do you think we can come to some kind of consensus that meets these goals? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Mon May 22 15:19:42 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 AB5F11293E4; Mon, 22 May 2017 15:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 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_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.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 8kEkQWFa2iKT; Mon, 22 May 2017 15:19:38 -0700 (PDT) Received: from homiemail-a124.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABD81272E1; Mon, 22 May 2017 15:19:38 -0700 (PDT) Received: from homiemail-a124.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a124.g.dreamhost.com (Postfix) with ESMTP id 3C33560000D00; Mon, 22 May 2017 15:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=Nz05IO1NsBfpXtaFlaWPXuvDnSo=; b=ZgLihgmtrCpKC/VviNR09HBmPn0J ALjXorRrieRDaDJqwskdlPGte5zsdP8gZ6LFnT7qlzoUk4504psaxIWfK9wvxzxb m8UjMShYowoZ9iy+dlEnPDEnDm551TLMAyRf2qnokRcnteqgk2llHYm/Gecmo0oJ OWsUJ0cqCk3UpGw= Received: from [192.168.1.11] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a124.g.dreamhost.com (Postfix) with ESMTPSA id 1739560001B0A; Mon, 22 May 2017 15:19:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: <07f64bc5-13f6-62a0-3c04-91c780f69672@andrew.cmu.edu> Date: Mon, 22 May 2017 15:19:37 -0700 Cc: Julian Reschke , IETF Discussion , art@ietf.org, Cyrus Daboo Content-Transfer-Encoding: quoted-printable Message-Id: <4803F47E-B29C-440A-91EA-F0D115208A53@gbiv.com> References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu>

<7bcfecea-3a89-978c-9e1b-edf9aac5dd44@gmx.de> <07f64bc5-13f6-62a0-3c04-91c780f69672@andrew.cmu.edu> To: Ken Murchison X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 22 May 2017 22:19:41 -0000 > On May 22, 2017, at 11:59 AM, Ken Murchison = wrote: > On 05/17/2017 09:58 AM, Julian Reschke wrote: >> On 2017-05-17 15:07, Ken Murchison wrote: >>> ... >>>> Only for creation of the attachment. Once is has been created, it >>>> should have its own URI, and the usual HTTP methods should be = applicable. >>>=20 >>> Using HTTP methods directly on the attachment URI makes things more >>> difficult because the calendar resource(s) referencing the = attachment >>> also need to be updated. This would have to be done either as a >>> side-effect of the PUT/DELETE on the attachment, or as a separate = PUT >>> (and separate round-trips) on the resource(s). The desire was to = avoid >>> doing either one of these, which is why a POST on the calendar = resource >>> was chosen as the method to add/update/delete an attachment from a >>> calendar resource. >>=20 >> But the POST is *not* on the calendar resource, but on the calendar = resource + query parameters, which, from HTTP's point of view is a = different resource already. >>=20 >> Furthermore, what URIs are used is orthogonal to the question of = which methods to use. >>=20 >> Why is >>=20 >> POST /calendar-entry?action=3Dremove&attachment=3Dxyz >>=20 >> easier to process than >>=20 >> DELETE /calendar-entry?attachment=3Dxyz >>=20 >> or >>=20 >> DELETE /calendar-entry/attachments/xyz >>=20 >> ? >=20 > The issue here is that a single calendar resource may contain multiple = events (recurring event with overrides) and a particular attachment may = be associated with more than one instance of that event. For this = reason, we felt it best to use the calendar resource as the gateway to = the attachments, thus allowing manipulating multiple instances of an = attachment in a single round-trip. Also, by preventing clients from = manipulating attachments directly, a CalDAV server isn't forced to alter = all calendar resources associated with a particular attachment. But that isn't relevant to the choices here. HTTP is not a filesystem. A single implementation (e.g., caldav resource) can handle a wide = variety of URLs (identified HTTP resources) with all sorts of co-dependencies in the state represented by those resources. They are all part of the = calendar. The method states the kind of action being made. Likewise, an identifier for the attachment associated with the calendar = entry doesn't have to be the same as the identifiers for interacting with the attachment directly. For example, the calendar might provide one = identifier for the original attachment, a second for the attachment currently = applicable to a given instance of an entry, and a third for updating future = instances of that repeating event (i.e., all defined by the server, not the = protocol). In any case, one of the cornerstones of caldav practice is that caldav provides just one interface to an abstract Calendar database normally accessed via many different protocols/systems. The Calendar should = already be maintaining coherence between entries and attachments, just like it shouldn't require a new entry be created every time the invitation list is expanded. > We also have a fairly large number of deployed implementations which = we do not want to make non-compliant by substantially modifying the = protocol. At this point, specifying the use of HTTP methods other than = POST would indeed make existing implementations non-compliant. Specifying method actions within URL query strings is well-known to be bad practice. However, if you are okay with specifying an IETF protocol that contains obviously bad practice in its application of HTTP, a minimum would be to reference section 4.2.1 of RFC7231, where it = states: When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action, it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, it is common for Web-based content editing software to use actions within query parameters, such as "page?do=3Ddelete". If the purpose of such = a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate side effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, building a search = index, etc. > We would definitely like to make this protocol conform to current HTTP = practice where possible, and would also document where we have strayed = from existing practice if required to do so. Do you think we can come = to some kind of consensus that meets these goals? >=20 > --=20 > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University I honestly don't see how this can be considered an extension of WebDAV and yet have such a profound misunderstanding of method semantics. Other applications of HTTP might be expected to work around PUT/DELETE, but not a WebDAV server. Likewise, defining a protocol in terms of predefined URL patterns and specific query components is fundamentally incompatible with REST. OTOH, it's not the first time this has come up. HTTP provides plenty of rope, for good reasons, and these types of choices seem only to harm those using the rope. Maybe a future version will just use HTTP. Cheers, Roy T. Fielding Senior Principal Scientist, Adobe From nobody Tue May 23 02:47:31 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 7F7CA129420; Tue, 23 May 2017 02:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Ez-lLF0WJO1l; Tue, 23 May 2017 02:47:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 AEE8A127286; Tue, 23 May 2017 02:47:27 -0700 (PDT) Received: from [192.168.1.57] ([217.91.35.233]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MS5xC-1dOlXi2WjK-00TCN0; Tue, 23 May 2017 11:47:08 +0200 To: Ken Murchison , IETF Discussion , art@ietf.org Cc: Cyrus Daboo References: <81613220-989b-ca78-fe56-0ac7b19e7ce6@andrew.cmu.edu>

<7bcfecea-3a89-978c-9e1b-edf9aac5dd44@gmx.de> <07f64bc5-13f6-62a0-3c04-91c780f69672@andrew.cmu.edu> From: Julian Reschke Message-ID: Date: Tue, 23 May 2017 11:47:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <07f64bc5-13f6-62a0-3c04-91c780f69672@andrew.cmu.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7KNd+yZ1YD/PcZza3Y88SmR+4MYllZbvuDHXsZQ4i2l/3MmcyJw bEcxTvLFaSZQwCKKpRa0ZnjE+LNWcMTv/RwWC1To4vIUgRr3fVpEZE67QaXTMEvfchk+dqW mL8vu2AjWP+x7uVHHazvxVF/F/zHucSWU4V2FU71GYiRhHHX5MPIkbW7x7PIfMbEWRRyf5d hvRDP7zaZ/XSJXbSYw8xQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:pDH/97rXxHQ=:huxfk6W9VCczUBE8q/RuRs g9oBuJpqBNRso3Wi/5gLYF24srbOdKuS3k80AckA48iP6saSdYVX4R4rQIUeUfJdvnK0wlw/1 lAblSSmQFo1WfM8QDVoUd+bMOcEC+8PGTgqtAxxnoYx/DNsHB/E+CnfqxvwHJ7ZSUtJ6sTug4 EKsQgV+/TTpBY8+CzRRhgjoyLRr7PL1m2Bv1iYdoW2PWxth/WFvEbNFMJpZy8okAbQqnTm5wH JIp0sJckXOP1ZGF6DwYzDiTCvoQgdV37M4zGjdtLzrXLj815Cfy5kMdAz+lYnkwjhORC/uHSN nJ94NyY++RxSBhhpUOBIBFh1HvMh/j9QGhY1nLBKFPwPJV4dwHG5sE7zCfOTgoMW9yWhRYASR kMLw2QO51ZRjx74AswEwlQIZK9R4Kp4aE9OQRz93hyGG6O3dlVRp0omztpMCe+K0IHTTx5xRO lKjbbAo4VjiqgRwmPXSfr13vxHFQl0mUIDpDDHW0oAgpTMOpvPzpP4fEzHtS+UNsLmstM4oTP yL8qdnNcc8sf5JBWNv+bHVdC7Qcpn/+Vq0TKaz2sIClUTwm4jOIWD9MY3z0GZNRBkmc5P0UgO B5QzrVPlBEJywuP/g6ixpErilbQms3mOC/Sylun8Ra6OC6Jvy9STZaC35J3cSDziJtAgLURos 7K5YJkiJDw8C7ELHIm373gLR4eKiaXqeY0nMDv4FEctf3NDr9OU8sgjB+t7ew2gYzPl8nZT1n VPDyZ08PyQzotX1/IzgA0LwcthrZje1nn5Mpyic2mcb6uQrJuC58E4ErR0tU9TOgXoD89hHfQ fjNuWXq Archived-At: Subject: Re: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2017 09:47:29 -0000 On 2017-05-22 20:59, Ken Murchison wrote: > ... > The issue here is that a single calendar resource may contain multiple > events (recurring event with overrides) and a particular attachment may > be associated with more than one instance of that event. For this > reason, we felt it best to use the calendar resource as the gateway to > the attachments, thus allowing manipulating multiple instances of an > attachment in a single round-trip. Also, by preventing clients from > manipulating attachments directly, a CalDAV server isn't forced to alter > all calendar resources associated with a particular attachment. > ... But that's a detail of how the server implements these resources. I still do not understand how the choice of HTTP methods and URI formats is relevant for that. > We also have a fairly large number of deployed implementations which we > do not want to make non-compliant by substantially modifying the > protocol. At this point, specifying the use of HTTP methods other than > POST would indeed make existing implementations non-compliant. Yes. > We would definitely like to make this protocol conform to current HTTP > practice where possible, and would also document where we have strayed > from existing practice if required to do so. Do you think we can come > to some kind of consensus that meets these goals? I'm just offering my feedback from an HTTP and web architecture point of view. And from that angle, the protocol as specified violates multiple best practices, and I would recommend not to publish it on the standards track. "Informational" might work, if this is indeed what's implemented, and implementers are unwilling to put more work into it... Best regards, Julian From nobody Thu May 25 11:51:42 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 E173912E037; Thu, 25 May 2017 11:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 6bku3iCcgjRk; Thu, 25 May 2017 11:51:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 EA1251293E0; Thu, 25 May 2017 11:51:40 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4PIpDuT008458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 11:51:13 -0700 (PDT) To: Matthew Miller , art@ietf.org Cc: ietf@ietf.org, draft-ietf-nfsv4-versioning.all@ietf.org, nfsv4@ietf.org References: <149462145126.13443.7366912235626631179@ietfa.amsl.com> From: Joe Touch Message-ID: Date: Thu, 25 May 2017 11:51:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149462145126.13443.7366912235626631179@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-nfsv4-versioning-09 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 25 May 2017 18:51:42 -0000 Hi, all, I'd like to add one point. This doc gives guidance on creating minor versions, but never addresses major versions. IMO, past variants of NFS have not handled major version changes appropriately. Each one has been assigned a new port number. This is no longer recommended practice (see RFC7605, Sec 7.5). Is this issue addressed in another document? AFAICT, if (when) NFSv5 is developed, it seems to appear to need another port number. If that's the case (and I sincerely hope it isn't), it MUST be the last one assigned to this service. Joe From nobody Thu May 25 12:33:25 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 97127127876; Thu, 25 May 2017 12:33:10 -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 CL6gi7cRHOZW; Thu, 25 May 2017 12:33:09 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 D6EF1126BF7; Thu, 25 May 2017 12:33:08 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id o5so62383650ith.1; Thu, 25 May 2017 12:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gskXHB8Plylia7vweZIvARanglO8dX5tSPPryRy6K0s=; b=qADyrPAKLpdOSJZSSOVb+Gwmf886GXkmrFV429242s/quP14GU3pvNpMyItpEACjVX uhv19CdQN+oUHoisUkfNq5AFZxpYoWZD7mhu1x5p5N3ijZRWsPv8EnjrAj6vREu6+aTe VPzN9LueYbrNvDcCSX97YOY6TK08XLq+kxESJB/GNGub0gCq7oy+SdJgBOh2ozky2F6s squBfSmavqq7wfB6UPABZTYF+t7BnSYW+s+3dk0iwExtUS+35AKbg8OowVJjaaCtI+b2 Q11hMX2JDaXgxy8baW5/XH+uPMZ6H9Jnn4j4qkNerHy4hDCblvLYKPUKlp0EENAKUjjS Htqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gskXHB8Plylia7vweZIvARanglO8dX5tSPPryRy6K0s=; b=XsgmbiQiwkQ1su6op3nagWLd2lvEil0c7Po8h2od+bYvpSluQrR5kUhWBPkB/ESHPk 2jVo47rY8CrNrTnTGpyh9gZ52hcSRLEwcOypnUOGpQpZ9AqyzCBp0eAzaKkYXTCcOgdD tuDRvKlUw+WuIBlZicohxmhs9cCwMxlPsqamaiSvh1zqNnQQq43kGnNpUy9qMKdfS8jE 4qqDWekjXcfDjG/eu4TkrjLfkGBpx7wHkDqfKMiWa5ZE8DGBxXTW70gYT81j5Uk+/5qb ErYaMEjy9+g/m1knzBhWdADGZCUj1rERSLDJh9HZWQ2GO4fiqe5oRac1uWa5Itg+av/B Od9A== X-Gm-Message-State: AODbwcCmec2PjkGSINXU642bJdoDQTgNNHmbfmwN/6mSp6VJ5RL41F13 /ymmO9r+Fmd77ZW6Qpb9EPjv5OypfQ== X-Received: by 10.36.11.68 with SMTP id 65mr16094591itd.80.1495740788093; Thu, 25 May 2017 12:33:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.4.148 with HTTP; Thu, 25 May 2017 12:33:07 -0700 (PDT) In-Reply-To: References: <149462145126.13443.7366912235626631179@ietfa.amsl.com> From: David Noveck Date: Thu, 25 May 2017 15:33:07 -0400 Message-ID: To: Joe Touch Cc: Matthew Miller , art@ietf.org, ietf@ietf.org, draft-ietf-nfsv4-versioning.all@ietf.org, "nfsv4@ietf.org" Content-Type: multipart/alternative; boundary="001a1140c4ee59bfcf05505e4a1f" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-nfsv4-versioning-09 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 25 May 2017 19:33:11 -0000 --001a1140c4ee59bfcf05505e4a1f Content-Type: text/plain; charset="UTF-8" > This doc gives guidance on creating minor versions, but never addresses > major versions. I think we had enough to do addressing minor versions and didn't want to speculate about a possible v5. after all, we're the nfsv4 working group and not the nfsvn working group. > IMO, past variants of NFS have not handled major version changes > appropriately. Each one has been assigned a new port number. This is no > longer recommended practice (see RFC7605, Sec 7.5). Makes sense. > Is this issue addressed in another document? I don't think so. > AFAICT, if (when) NFSv5 is developed, it seems to appear to need another > port number. I don't see why it would. If there is another Rpc version of the NFS program, I don't see why the appropriate negotiation could be defined. I think doing\ that would be up to those defining nfsv5. > If that's the case (and I sincerely hope it isn't), it MUST > be the last one assigned to this service. I don't think "MUST" is appropriate in this case but I would say that assigning another port would be a DAMN SHAME. On Thu, May 25, 2017 at 2:51 PM, Joe Touch wrote: > Hi, all, > > I'd like to add one point. > > This doc gives guidance on creating minor versions, but never addresses > major versions. > > IMO, past variants of NFS have not handled major version changes > appropriately. Each one has been assigned a new port number. This is no > longer recommended practice (see RFC7605, Sec 7.5). > > Is this issue addressed in another document? > > AFAICT, if (when) NFSv5 is developed, it seems to appear to need another > port number. If that's the case (and I sincerely hope it isn't), it MUST > be the last one assigned to this service. > > Joe > --001a1140c4ee59bfcf05505e4a1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> This doc gives guida= nce on creating minor versions, but never addresses
> major versions.<= div>

I think we had enough to do addressing minor versions an= d didn't want to

speculate about a possible v5. =C2=A0after a= ll, we're the nfsv4 working group

and not the nfsvn working g= roup.

> IMO, past variants of NFS have not handled major version chan= ges
&= gt; appropriately. Each one has been assigned a new port number. This is no=
>= longer recommended practice (see RFC7605, Sec 7.5).

Makes sense.

> Is this issue addressed in another document?

I don't think so.

> AFAICT, if (when) NFSv5 is developed, it seems t= o appear to need another
> port number.=C2=A0

I don't see why it would.=C2=A0 If there is another Rpc version of th= e NFS program,

I don'= t see why the appropriate negotiation could be defined.=C2=A0 I think doing= \

that would be up to tho= se defining nfsv5.

> If that's the cas= e (and I sincerely hope it isn't), it MUST
> be the last one assigned to = this service.

I don't think "M= UST" is appropriate in this case but I would say that assigning=C2=A0<= /div>

another port would be a DAMN SHAME.

On Thu, May 25, 2017 at 2:51 PM, Jo= e Touch <touch@isi.edu> wrote:

Hi, all,

I'd like to add one point.

This doc gives guidance on creating minor versions, but never addresses
major versions.

IMO, past variants of NFS have not handled major version changes
appropriately. Each one has been assigned a new port number. This is no
longer recommended practice (see RFC7605, Sec 7.5).

Is this issue addressed in another document?

AFAICT, if (when) NFSv5 is developed, it seems to appear to need another port number. If that's the case (and I sincerely hope it isn't), it= MUST
be the last one assigned to this service.

Joe

--001a1140c4ee59bfcf05505e4a1f-- From nobody Thu May 25 15:18:24 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 31DF9127B52; Thu, 25 May 2017 15:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 YEQN_6obsKYx; Thu, 25 May 2017 15:18:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 C2F31129B21; Thu, 25 May 2017 15:18:15 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4PMHhQw019774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 15:17:57 -0700 (PDT) To: David Noveck Cc: Matthew Miller , art@ietf.org, ietf@ietf.org, draft-ietf-nfsv4-versioning.all@ietf.org, "nfsv4@ietf.org" References: <149462145126.13443.7366912235626631179@ietfa.amsl.com> From: Joe Touch Message-ID: Date: Thu, 25 May 2017 15:17:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AC254B0531D11EB8A41583A9" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-nfsv4-versioning-09 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 25 May 2017 22:18:17 -0000 This is a multi-part message in MIME format. --------------AC254B0531D11EB8A41583A9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, David, Thanks for the response, and agreed throughout. Joe On 5/25/2017 12:33 PM, David Noveck wrote: > > This doc gives guidance on creating minor versions, but never addresses > > major versions. > > I think we had enough to do addressing minor versions and didn't want to > speculate about a possible v5. after all, we're the nfsv4 working group > and not the nfsvn working group. > > > > IMO, past variants of NFS have not handled major version changes > > appropriately. Each one has been assigned a new port number. This is no > > longer recommended practice (see RFC7605, Sec 7.5). > > > Makes sense. > > > Is this issue addressed in another document? > > I don't think so. > > > AFAICT, if (when) NFSv5 is developed, it seems to appear to need another > > port number. > > I don't see why it would. If there is another Rpc version of the NFS > program, > I don't see why the appropriate negotiation could be defined. I think > doing\ > that would be up to those defining nfsv5. > > > If that's the case (and I sincerely hope it isn't), it MUST > > be the last one assigned to this service. > > I don't think "MUST" is appropriate in this case but I would say that > assigning > another port would be a DAMN SHAME. > > On Thu, May 25, 2017 at 2:51 PM, Joe Touch > wrote: > > Hi, all, > > I'd like to add one point. > > This doc gives guidance on creating minor versions, but never > addresses > major versions. > > IMO, past variants of NFS have not handled major version changes > appropriately. Each one has been assigned a new port number. This > is no > longer recommended practice (see RFC7605, Sec 7.5). > > Is this issue addressed in another document? > > AFAICT, if (when) NFSv5 is developed, it seems to appear to need > another > port number. If that's the case (and I sincerely hope it isn't), > it MUST > be the last one assigned to this service. > > Joe > > --------------AC254B0531D11EB8A41583A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, David,

Thanks for the response, and agreed throughout.

Joe

On 5/25/2017 12:33 PM, David Noveck wrote:

> This doc gives guidance on creating minor versions, but never addresses
> major versions.

I think we had enough to do addressing minor versions and didn't want to

speculate about a possible v5. after all, we're the nfsv4 working group

and not the nfsvn working group.

> IMO, past variants of NFS have not handled major version changes
> appropriately. Each one has been assigned a new port number. This is no
> longer recommended practice (see RFC7605, Sec 7.5).

Makes sense.

> Is this issue addressed in another document?

I don't think so.

> AFAICT, if (when) NFSv5 is developed, it seems to appear to need another
> port number.

I don't see why it would. If there is another Rpc version of the NFS program,

I don't see why the appropriate negotiation could be defined. I think doing\

that would be up to those defining nfsv5.

> If that's the case (and I sincerely hope it isn't), it MUST
> be the last one assigned to this service.

I don't think "MUST" is appropriate in this case but I would say that assigning

another port would be a DAMN SHAME.

On Thu, May 25, 2017 at 2:51 PM, Joe Touch <touch@isi.edu> wrote:

Hi, all,

I'd like to add one point.

This doc gives guidance on creating minor versions, but never addresses
major versions.

IMO, past variants of NFS have not handled major version changes
appropriately. Each one has been assigned a new port number. This is no
longer recommended practice (see RFC7605, Sec 7.5).

Is this issue addressed in another document?

AFAICT, if (when) NFSv5 is developed, it seems to appear to need another
port number. If that's the case (and I sincerely hope it isn't), it MUST
be the last one assigned to this service.

Joe

--------------AC254B0531D11EB8A41583A9-- From nobody Thu May 25 15:43:22 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 86FA2127B52 for ; Thu, 25 May 2017 15:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 INbc5WJmDJBP for ; Thu, 25 May 2017 15:43:12 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (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 4D816129BC4 for ; Thu, 25 May 2017 15:43:12 -0700 (PDT) Received: from [10.137.198.25] ([131.107.147.196]) by :SMTPAUTH: with SMTP id E1QedC8pzqTuIE1QfdErrA; Thu, 25 May 2017 15:40:25 -0700 To: Joe Touch , David Noveck Cc: art@ietf.org, Matthew Miller , ietf@ietf.org, draft-ietf-nfsv4-versioning.all@ietf.org, "nfsv4@ietf.org" References: <149462145126.13443.7366912235626631179@ietfa.amsl.com>

From: Tom Talpey Message-ID: Date: Thu, 25 May 2017 15:40:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfFgqD0Unhil59tIg+xyBVNyA8nfVrdu/pl43zl5VLTnxYXaYTJQ5vHzUmi/HSQwbdd0rzNDK2bJmbO+7bbwkA0NNAlSuQfLhaXOfqpJaEXi/WZPeCKIC koow8ZkNj5G7Hr749yuPzogX6ls5jrMAKQEpql0mnhwcQJf8EwDntULSfGCDVdNM2hWxcikf/PITQTwHZe9V2JK3g8vlECQjgc67gAtQbrZVjzppXkYMDui7 J9frzljPjEUofnPJL1PTsed84xcdYWNSwjK2fI6sWM9ykvymW6fY+IZBAFVfxl5wmrJvqoWefOezkw9P3Gdi868HURw00/tIwYgMiAq04CB1rXJQIdLHt3B9 1jVHu9LdmBOQPiFik+8MoKU3cqff8Q== Archived-At: Subject: Re: [art] [nfsv4] Artart last call review of draft-ietf-nfsv4-versioning-09 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 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, 25 May 2017 22:43:13 -0000 On 5/25/2017 3:17 PM, Joe Touch wrote: > Hi, David, > > Thanks for the response, and agreed throughout. > > Joe > > > On 5/25/2017 12:33 PM, David Noveck wrote: >> > This doc gives guidance on creating minor versions, but never addresses >> > major versions. >> >> I think we had enough to do addressing minor versions and didn't want to >> speculate about a possible v5. after all, we're the nfsv4 working group >> and not the nfsvn working group. >> >> >> > IMO, past variants of NFS have not handled major version changes >> > appropriately. Each one has been assigned a new port number. This is no >> > longer recommended practice (see RFC7605, Sec 7.5). I feel compelled to chime in on this one. NFS has always had a single assigned port, 2049, which has not changed with major version. In the NFSv2 days, it was self-assigned by Sun Microsystems, later, in NFSv3, it was registered with IANA. For both versions, the RPC portmapper was used by clients to resolve the server port. In NFSv4, the portmapper is not used, but the port number assignment did not change. This remains true for all NFSv4 minor versions. There is one exception - NFS over RDMA received a new port assignment from IANA, 20049, because the NFSv2 and NFSv3 protocols could not negotiate the NFS/RDMA listener using legacy portmapping. While the NFSv4.1+ versions provide a mechanism for that, the static 20049 assignment is still recommended. Bottom line, the NFS ports are stable and registered, and there is no need to allocate more, at least as foreseen at this time. Tom. >> >> >> Makes sense. >> >> > Is this issue addressed in another document? >> >> I don't think so. >> >> > AFAICT, if (when) NFSv5 is developed, it seems to appear to need another >> > port number. >> >> I don't see why it would. If there is another Rpc version of the NFS >> program, >> I don't see why the appropriate negotiation could be defined. I think >> doing\ >> that would be up to those defining nfsv5. >> >> > If that's the case (and I sincerely hope it isn't), it MUST >> > be the last one assigned to this service. >> >> I don't think "MUST" is appropriate in this case but I would say that >> assigning >> another port would be a DAMN SHAME. >> >> On Thu, May 25, 2017 at 2:51 PM, Joe Touch > > wrote: >> >> Hi, all, >> >> I'd like to add one point. >> >> This doc gives guidance on creating minor versions, but never >> addresses >> major versions. >> >> IMO, past variants of NFS have not handled major version changes >> appropriately. Each one has been assigned a new port number. This >> is no >> longer recommended practice (see RFC7605, Sec 7.5). >> >> Is this issue addressed in another document? >> >> AFAICT, if (when) NFSv5 is developed, it seems to appear to need >> another >> port number. If that's the case (and I sincerely hope it isn't), >> it MUST >> be the last one assigned to this service. >> >> Joe >> >> > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 > From nobody Fri May 26 06:56:14 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 BF63A1295A0; Fri, 26 May 2017 06:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BJYYDOLbekoA; Fri, 26 May 2017 06:56:10 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 5B329129557; Fri, 26 May 2017 06:56:10 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id p143so2486582yba.2; Fri, 26 May 2017 06:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QbgESz2P5pihaesDmUyn+g7NyG0lkgY6SPwSrI7In2g=; b=PdILL1YdF7KENgyvat8Fbh8sQuCWIecnZ2TcyzPqVp2vv871UQ8bTZip0MAgG3GqAR imnenKPonQSRQc4XXwXaEbGWrQB2NYqJXnnJsBbVijsqZj9UEO6si6IrEZJAxgulkw9h thSwzTJVU3l4trd0o8MEr7NTUW499zDuXE4MmW6qP9EH25QhqH38vLT5EsTkFWQcKcrW VcbIkqA9m09M678mi22K9G01UC72pxPYGlokYrFfiCS1kC4ZoiEBa+rznPWhLOJlgsF9 71CF8zFkwDmyc/KWyHBuhdYBWEUpGECFpLcBV+hoy+yrkh+Jyvof9Q7YbbA3CSMQZDY3 eRaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QbgESz2P5pihaesDmUyn+g7NyG0lkgY6SPwSrI7In2g=; b=LwI/e+R0FIz7JrmhjCjiyXtctNjr0gPI4QrgA4gi7BazX7klVF4ibSYdFPqZCBwv/a DgvwX3hYOM7DAl41mY0LUws9O77zW9w6JKqHN7DKVk4oqIiGE9tUgl7al8dXM1hQk2Uf a5360kzsARpnPhb7RAYNcxx0OBuw4erzw9xyLVelWrFdH9M3PGaLkjr8KQ/zOaL05WDq 3omoaThnPmFw8I9OZhLMBVu9bHakmJQt31louFUmsvvlZdsr0ktXmK8EVkNHoCp4o1QV hf2YYLZgI820ZEUespXee1hDQdOW9f5oMLaQ4yrDx7AIEwy4uNzQJk1YMWkcAjzsvowA 5+Jw== X-Gm-Message-State: AODbwcCKGzPje4cmUx4ZxrtInXIz6ciawZ5p8khHwiK9UqtJePVU3O06 Yi2IFympVApY5UGcXly7ElJQx0FD1g== X-Received: by 10.37.15.213 with SMTP id 204mr36918032ybp.127.1495806969674; Fri, 26 May 2017 06:56:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.195.194 with HTTP; Fri, 26 May 2017 06:56:09 -0700 (PDT) In-Reply-To: References: <149462145126.13443.7366912235626631179@ietfa.amsl.com>

From: Spencer Dawkins at IETF Date: Fri, 26 May 2017 09:56:09 -0400 Message-ID: To: Tom Talpey Cc: Joe Touch , David Noveck , art@ietf.org, Matthew Miller , "ietf@ietf.org" , draft-ietf-nfsv4-versioning.all@ietf.org, "nfsv4@ietf.org" Content-Type: multipart/alternative; boundary="001a113f5ae614861805506db374" Archived-At: Subject: Re: [art] [nfsv4] Artart last call review of draft-ietf-nfsv4-versioning-09 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 13:56:13 -0000 --001a113f5ae614861805506db374 Content-Type: text/plain; charset="UTF-8" Hi, Tom, On Thu, May 25, 2017 at 6:40 PM, Tom Talpey wrote: > On 5/25/2017 3:17 PM, Joe Touch wrote: > >> Hi, David, >> >> Thanks for the response, and agreed throughout. >> >> Joe >> >> >> On 5/25/2017 12:33 PM, David Noveck wrote: >> >>> > This doc gives guidance on creating minor versions, but never addresses >>> > major versions. >>> >>> I think we had enough to do addressing minor versions and didn't want to >>> speculate about a possible v5. after all, we're the nfsv4 working group >>> and not the nfsvn working group. >>> >>> >>> > IMO, past variants of NFS have not handled major version changes >>> > appropriately. Each one has been assigned a new port number. This is no >>> > longer recommended practice (see RFC7605, Sec 7.5). >>> >> > I feel compelled to chime in on this one. NFS has always had a single > assigned port, 2049, which has not changed with major version. In the > NFSv2 days, it was self-assigned by Sun Microsystems, later, in NFSv3, > it was registered with IANA. For both versions, the RPC portmapper was > used by clients to resolve the server port. > > In NFSv4, the portmapper is not used, but the port number assignment > did not change. This remains true for all NFSv4 minor versions. > > There is one exception - NFS over RDMA received a new port assignment > from IANA, 20049, because the NFSv2 and NFSv3 protocols could not > negotiate the NFS/RDMA listener using legacy portmapping. While the > NFSv4.1+ versions provide a mechanism for that, the static 20049 > assignment is still recommended. > > Bottom line, the NFS ports are stable and registered, and there is no > need to allocate more, at least as foreseen at this time. Thanks for the history on port allocations, which I lacked, and I'm glad that your answer is the right answer :-) > Tom. > >> >>> >>> Makes sense. >>> >>> > Is this issue addressed in another document? >>> >>> I don't think so. >>> >>> > AFAICT, if (when) NFSv5 is developed, it seems to appear to need >>> another >>> > port number. >>> I don't see why it would. If there is another Rpc version of the NFS >>> program, >>> I don't see why the appropriate negotiation could be defined. I think >>> doing\ >>> that would be up to those defining nfsv5. >>> >>> > If that's the case (and I sincerely hope it isn't), it MUST >>> > be the last one assigned to this service. >>> >>> I don't think "MUST" is appropriate in this case but I would say that >>> assigning >>> another port would be a DAMN SHAME. >>> >>> On Thu, May 25, 2017 at 2:51 PM, Joe Touch >> touch@isi.edu>> wrote: >>> >>> Hi, all, >>> >>> I'd like to add one point. >>> >>> This doc gives guidance on creating minor versions, but never >>> addresses >>> major versions. >>> >>> IMO, past variants of NFS have not handled major version changes >>> appropriately. Each one has been assigned a new port number. This >>> is no >>> longer recommended practice (see RFC7605, Sec 7.5). >>> >>> Is this issue addressed in another document? >>> >>> AFAICT, if (when) NFSv5 is developed, it seems to appear to need >>> another >>> port number. If that's the case (and I sincerely hope it isn't), >>> it MUST >>> be the last one assigned to this service. >>> >>> Joe >>> >>> >>> >> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www.ietf.org/mailman/listinfo/nfsv4 >> >> --001a113f5ae614861805506db374 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, Tom,

On Thu, May 25, 2017 at 6:40 PM, Tom Talpey <<= a href=3D"mailto:tom@talpey.com" target=3D"_blank">tom@talpey.com> wrote:

On 5/25/201= 7 3:17 PM, Joe Touch wrote:

Hi, David,

Thanks for the response, and agreed throughout.

Joe

On 5/25/2017 12:33 PM, David Noveck wrote:

> This doc gives guidance on creating minor versions, but never addresse= s
> major versions.

I think we had enough to do addressing minor versions and didn't want t= o
speculate about a possible v5.=C2=A0 after all, we're the nfsv4 working= group
and not the nfsvn working group.

> IMO, past variants of NFS have not handled major version changes
> appropriately. Each one has been assigned a new port number. This is n= o
> longer recommended practice (see RFC7605, Sec 7.5).

I feel compelled to chime in on this one. NFS has always had a single
assigned port, 2049, which has not changed with major version. In the
NFSv2 days, it was self-assigned by Sun Microsystems, later, in NFSv3,
it was registered with IANA. For both versions, the RPC portmapper was
used by clients to resolve the server port.

In NFSv4, the portmapper is not used, but the port number assignment
did not change. This remains true for all NFSv4 minor versions.

There is one exception - NFS over RDMA received a new port assignment
from IANA, 20049, because the NFSv2 and NFSv3 protocols could not
negotiate the NFS/RDMA listener using legacy portmapping. While the
NFSv4.1+ versions provide a mechanism for that, the static 20049
assignment is still recommended.

Bottom line, the NFS ports are stable and registered, and there is no
need to allocate more, at least as foreseen at this time.

Thanks for the history on port allocations, which I lacked, = and I'm glad that your answer is the right answer :-)

=C2=A0<= /div>

Tom.

Makes sense.

> Is this issue addressed in another document?

I don't think so.

> AFAICT, if (when) NFSv5 is developed, it seems to appear to need anoth= er
> port number.
I don't see why it would. If there is another Rpc version of the NFS pr= ogram,
I don't see why the appropriate negotiation could be defined.=C2=A0 I t= hink doing\
that would be up to those defining nfsv5.

> If that's the case (and I sincerely hope it isn't), it MUST > be the last one assigned to this service.

I don't think "MUST" is appropriate in this case but I would = say that assigning
another port would be a DAMN SHAME.

On Thu, May 25, 2017 at 2:51 PM, Joe Touch <touch@isi.edu <mailto:touch@isi.edu>> wrote:

=C2=A0 =C2=A0 Hi, all,

=C2=A0 =C2=A0 I'd like to add one point.

=C2=A0 =C2=A0 This doc gives guidance on creating minor versions, but never=
=C2=A0 =C2=A0 addresses
=C2=A0 =C2=A0 major versions.

=C2=A0 =C2=A0 IMO, past variants of NFS have not handled major version chan= ges
=C2=A0 =C2=A0 appropriately. Each one has been assigned a new port number. = This
=C2=A0 =C2=A0 is no
=C2=A0 =C2=A0 longer recommended practice (see RFC7605, Sec 7.5).

=C2=A0 =C2=A0 Is this issue addressed in another document?

=C2=A0 =C2=A0 AFAICT, if (when) NFSv5 is developed, it seems to appear to n= eed
=C2=A0 =C2=A0 another
=C2=A0 =C2=A0 port number. If that's the case (and I sincerely hope it = isn't),
=C2=A0 =C2=A0 it MUST
=C2=A0 =C2=A0 be the last one assigned to this service.

=C2=A0 =C2=A0 Joe

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

--001a113f5ae614861805506db374--