From nobody Tue Apr 5 12:02:24 2022 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1CD3A23D0; Tue, 5 Apr 2022 12:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqfIM5hXs2HW; Tue, 5 Apr 2022 12:01:57 -0700 (PDT) Received: from rfcpa.amsl.com (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B343A23B2; Tue, 5 Apr 2022 12:01:47 -0700 (PDT) Received: by rfcpa.amsl.com (Postfix, from userid 499) id 7D0873BA9D; Tue, 5 Apr 2022 12:01:46 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, jmap@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20220405190146.7D0873BA9D@rfcpa.amsl.com> Date: Tue, 5 Apr 2022 12:01:46 -0700 (PDT) Archived-At: Subject: [Jmap] =?utf-8?q?RFC_9219_on_S/MIME_Signature_Verification_Exten?= =?utf-8?q?sion_to_the_JSON_Meta_Application_Protocol_=28JMAP=29?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 19:02:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9219 Title: S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) Author: A. Melnikov Status: Standards Track Stream: IETF Date: April 2022 Mailbox: Alexey.Melnikov@isode.com Pages: 10 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-jmap-smime-12.txt URL: https://www.rfc-editor.org/info/rfc9219 DOI: 10.17487/RFC9219 This document specifies an extension to "The JSON Meta Application Protocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status. This document is a product of the JSON Mail Access Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Apr 6 12:04:37 2022 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A643E3A0E5F; Wed, 6 Apr 2022 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 hJ8tGAFa7T3t; Wed, 6 Apr 2022 12:04:09 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 4D5883A0E47; Wed, 6 Apr 2022 12:04:09 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id kc20so3043021qvb.3; Wed, 06 Apr 2022 12:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=mHBG2Zml6brubXM1r9Dp3D9+HdWrUhuSeEmYb5R+4F0=; b=c1uCXPa7DRawuubfCgtpCxKHNrL4yyHZDKnKQAIuHfh5pxcmsY9bovasjUcQc2uskZ IJqQNf/BMJByBLbL8i1wdCVZ8D/SYHtEYHdpaa3Oe22+XF2JbY2vp7/67tUDf+hM+9aP cs91B3bF3czs3qkrC8xFon2DkwNUPUCZ4SRTTNkXZNyt81vGWSrg6By3Tv6xo4JK2m75 gsrYB175hDeBUkK2xjp5U52Gpe7auVN3fiQvLlhWQo3dyo7x9NcwCZ+W+Eot+YwwZbRV cF/peLn9q/ac5VOWyeTOGTBx47y5kdGctGyJi+GeXXA36v0iNUAGIbnKW4+UaHZlGL4d pAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=mHBG2Zml6brubXM1r9Dp3D9+HdWrUhuSeEmYb5R+4F0=; b=SH0mTy0mH37nryVKqak1bTtSn6EjTPjxHrBh2EEwwN3KxUEJJfI+dQ4aIbJ6190JZD kZzY+i1XQLafRkeXBGPH0aRras0tp6vTdC8mzYaqUaEb0K38p/MT0LaniMBtNG5kAbqK s16Q2vao0XTux1b7z/jZvsDi6wbGL7qEfssoJkMEiteL580mc0afon/3DLSMlP2n1e2U CEBIAiTWQK35oPMfIiNub83QfVHB7Lx5Ia71TVq1tp7XodpBeEqZ5F99UryFZEZM6JSc vXD2qYyVD+KR3HqP2gY870HMrwUOc4uOXI1JguJuWmCggcMxtqBu4gYe/XtQHKsgjQvp 8kGw== X-Gm-Message-State: AOAM531xGTaUU2CX1LtW74O+Ln9OMqwe9yLAfoqfIzdpIGITh0/luSGE PZu5QM2svJX2sxy7V3rl35c= X-Google-Smtp-Source: ABdhPJyLbnYL1d53NFXsnY0TFjr0uK8mdMHNncfPiGFHxd27jwrNE0JC98wzIxlOGXrUas6T96CPxA== X-Received: by 2002:a05:6214:c64:b0:443:a483:3451 with SMTP id t4-20020a0562140c6400b00443a4833451mr9016881qvj.30.1649271847707; Wed, 06 Apr 2022 12:04:07 -0700 (PDT) Received: from [192.168.1.151] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id m4-20020ac85b04000000b002e1dcaed228sm12845605qtw.7.2022.04.06.12.04.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Apr 2022 12:04:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------yjMHlxF0RGzvySR4bCmVsi1B" Message-ID: <7b21aab2-2eb1-a99a-1f32-8145f456c448@gmail.com> Date: Wed, 6 Apr 2022 15:04:05 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Joris Baum , calsify@ietf.org, jmap@ietf.org Cc: =?UTF-8?Q?Happel_Hans-J=c3=b6rg?= References: <32d05385-b458-696c-96a6-a97a2409a090@audriga.com> From: Michael Douglass In-Reply-To: <32d05385-b458-696c-96a6-a97a2409a090@audriga.com> Archived-At: Subject: Re: [Jmap] [calsify] draft-ietf-calext-ical-tasks-03 Review X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2022 19:04:15 -0000 This is a multi-part message in MIME format. --------------yjMHlxF0RGzvySR4bCmVsi1B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Joris. Sorry not to have responded sooner. All good points - I'll try to get a more detailed reply along with some changes soon. On 3/29/22 08:08, Joris Baum wrote: > > Hi, > > > I just had a look at the draft-ietf-calext-ical-tasks-03 spec. In > general, it looks good to me. Most of my comments are small things > which might or might not require some more clarification. > > General note: Typically, collaborative software development tools > allow tracking the changes to any task property. Such a > "history"-feature is most likely out of scope for that draft, but it > looks like `VSTATUS` could be used (to some extent) for that feature. > Maybe it would make sense to state in the draft that tracking history > of all properties is not covered by the spec? > > Section 4: > > * Task Actors mentions "Organizer" as an actor. In the picture, it > is not part of that group. I suggest to either leave it out in the > text or change the group name in the picture (probably the latter). > * The Task Actors roles seem to be purely informational. Maybe it > would make sense to specify how they are supposed to be mapped to > an iCalendar equivalent, like `ORGANIZER`? > > Section 12.2: > > * A "name-space" is mentioned, but it seems to be not defined what a > "name-space" should look like. > * When using IANA registered values for `REASON` as done in one of > the examples (`REASON:out-of-office`) do not seem to be of `URI` > type. I guess that is not in line with its definition? > > > The following are probably merely minor notes (about spelling, style > and copy+paste errors). You would probably have found them yourself > before a WGLC, but I think it does not hurt to include them: > > Section 7.2: > > * "See section 3.1.3 Task Domain Data Handling." You probably meant > section 7.3 ? > * "Extensions [Doug114] to the RELATED-TO" Reference not included. > You probably meant draft-ietf-calext-ical-relations ? > * REL is used as a param in the examples, e.g. > `LINK;REL="vacation-system";VALUE=URI:http://example.com/vacation-approval?id=1234`. > But it is not part of draft-ietf-calext-ical-relations. I guess it > comes from an earlier version of the spec? > > Section 9: "In addition a number of different patterns of resource or > assignee identification are anticipated." - "In addition, a number of > different patterns of resource or assignee identification are > anticipated." (very minor, but it confused me for a short while) > > Section 10.3: "As situations chnage further VSTATUS components" → "As > situations change further VSTATUS components" > > Section 10.4: > > * "Alarms (VLARM components)" → "Alarms (VALARM components)" > * "Task Generating System, e.g., a BPMS" → Maybe specify what a BPMS > is. However, Wikipedia seems to understand it. > > Section 19: I am unable to open or find the [TARCH] reference? > > > Regards, > > Joris > > > -- > Joris Baum > Tel: +49 721 170293 16 > Fax: +49 721 170293 179 > > http://www.audriga.com |http://www.twitter.com/audriga > > -------------------------------------------------------------------------- > audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe > Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 > Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel > -------------------------------------------------------------------------- > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------yjMHlxF0RGzvySR4bCmVsi1B Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Joris.

Sorry not to have responded sooner. All good points - I'll try to get a more detailed reply along with some changes soon.

On 3/29/22 08:08, Joris Baum wrote:

Hi,


I just had a look at the draft-ietf-calext-ical-tasks-03 spec. In general, it looks good to me. Most of my comments are small things which might or might not require some more clarification.

General note: Typically, collaborative software development tools allow tracking the changes to any task property. Such a "history"-feature is most likely out of scope for that draft, but it looks like `VSTATUS` could be used (to some extent) for that feature. Maybe it would make sense to state in the draft that tracking history of all properties is not covered by the spec?

Section 4:

  • Task Actors mentions "Organizer" as an actor. In the picture, it is not part of that group. I suggest to either leave it out in the text or change the group name in the picture (probably the latter).
  • The Task Actors roles seem to be purely informational. Maybe it would make sense to specify how they are supposed to be mapped to an iCalendar equivalent, like `ORGANIZER`?

Section 12.2:

  • A "name-space" is mentioned, but it seems to be not defined what a "name-space" should look like.
  • When using IANA registered values for `REASON` as done in one of the examples (`REASON:out-of-office`) do not seem to be of `URI` type. I guess that is not in line with its definition?


The following are probably merely minor notes (about spelling, style and copy+paste errors). You would probably have found them yourself before a WGLC, but I think it does not hurt to include them:

Section 7.2:

  • "See section 3.1.3 Task Domain Data Handling." You probably meant section 7.3 ?
  • "Extensions [Doug114] to the RELATED-TO" Reference not included. You probably meant draft-ietf-calext-ical-relations ?
  • REL is used as a param in the examples, e.g. `LINK;REL="vacation-system";VALUE=URI:http://example.com/vacation-approval?id=1234`. But it is not part of draft-ietf-calext-ical-relations. I guess it comes from an earlier version of the spec?

Section 9: "In addition a number of different patterns of resource or assignee identification are anticipated." - "In addition, a number of different patterns of resource or assignee identification are anticipated." (very minor, but it confused me for a short while)

Section 10.3: "As situations chnage further VSTATUS components" → "As situations change further VSTATUS components"

Section 10.4:

  • "Alarms (VLARM components)" → "Alarms (VALARM components)"
  • "Task Generating System, e.g., a BPMS" → Maybe specify what a BPMS is. However, Wikipedia seems to understand it.

Section 19: I am unable to open or find the [TARCH] reference?


Regards,

Joris


-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com | http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------yjMHlxF0RGzvySR4bCmVsi1B--