From nobody Wed May 1 09:09:16 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FFB120108 for ; Wed, 1 May 2019 09:09:14 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=m7cbLbbF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Rb/U/XMa 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 ISv3sdCk_OGo for ; Wed, 1 May 2019 09:09:12 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32E9120077 for ; Wed, 1 May 2019 09:09:12 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id BEC78418 for ; Wed, 1 May 2019 12:09:11 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 01 May 2019 12:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=uguZJWosQ0HcsOZ9ota9itp/X5aUkOJBgkuxCxd UalE=; b=m7cbLbbFJkoinBcPpTNTRwVZr+Bp52Im6bX4EtVlfEzsmENtrcjej6n djNBaWih1h7VCofXtCLKcSeIRUfqa8yEBhybC0bcj4esI0nIv+jGVopN5o2PR8Qg Qq4G0w7MGJk/ICtDhHn4B55zToNDzxjrSWPVlMo0xnUI9FSr0VI/IKJCG5Ln24k2 04/GtF04TWHf1kM6H+15txdUHCCyDvUCwjvTRXw+unxLtf8Yl+RjAXqd9VvQy6li 2lvBjhLrpV/lv7nMmepn8PJsQ50p7Iz/dtjiLiI9vKLWBo/BYJvYmc3En8qqYL5/ Qa9AD9lMfn198NIyEv1Cf/kkre6ajUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=uguZJWosQ0HcsOZ9ota9itp/X5aUk OJBgkuxCxdUalE=; b=Rb/U/XMact5b5gXv+spmjItsy2+WC0dw/nJuVKVBgSVUl RyUZbOvgMJCqGeSVwQK/qFcEFVr+AtVcaPDNpyKbfcnMqe99ZYLeRtctTESqp+H+ 4FPU0riddaT2Rcom1oyO/pIwn1fBpmC/cHWrnWp+ebiWnsECXaVjMLdZMxjGOKrB uTFrtSPce+Vxnt8NYw2lrjjwRYje+/GaXeGUX8WCdjk+UytjJI3+yHCveoPxokfo SdyIIMQT0HsjvsrjJdp4sCgoIZ8FjHfSJpko/1t6E0ZN/wod+NoBE0tZH0ESVXs9 8VvYzfAb4aVppARWOCHC8YYM5iU0ZMLqiDOde1hHg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieejgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonh hgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AE75E211BC; Wed, 1 May 2019 12:09:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <49ae6861-d60c-45fa-9b8f-ee8c2bae8b7d@www.fastmail.com> Date: Wed, 01 May 2019 12:09:10 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a7ae25462a1c4ed2be66449e4ce631e2 Archived-At: Subject: [calsify] JSCalendar format for individual recurrences X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 16:09:14 -0000 --a7ae25462a1c4ed2be66449e4ce631e2 Content-Type: text/plain iMIP (RFC6047) messages can contain iTIP (RFC5546) files which refer to just a single recurrence of a full event. JSCalendar doesn't have an easy way to specify this kind of "orphan" event, I'm considering that maybe it looks like this: BASE EVENT: { "duration" : "PT1H", "recurrenceRule" : { "frequency" : "monthly" }, "start" : "2016-01-01T13:00:00", "timeZone" : "Europe/Vienna", "title" : "foo", "uid" : "89eee195-600b-423b-b3a6-52b3a420e556", [...] } OVERRIDE: { "recurrenceOverrides": { "2016-03-01T13:00:00": { "duration" : "PT2H", "start" : "2016-03-01T13:00:00", "timeZone" : "Europe/Vienna", "title" : "longfoo", [...] }, }, "uid" : "89eee195-600b-423b-b3a6-52b3a420e556", } COMBINED EVENT: { "duration" : "PT1H", "recurrenceOverrides": { "2016-03-01T13:00:00": { "duration" : "PT2H", "title" : "longfoo", }, }, "recurrenceRule" : { "frequency" : "monthly" }, "start" : "2016-01-01T13:00:00", "timeZone" : "Europe/Vienna", "title" : "foo", "uid" : "89eee195-600b-423b-b3a6-52b3a420e556", [...] } WHERE [...] is all the other properties. They have to be duplicated inside the recurrenceOverride when it's orphaned, because we don't have the parent event to refer to. I THINK this format is sufficient for representing a single recurrence, but let me know if you think I'm missing something. Should this have a separate @type key to tell you that it's an orphan or is the presence of recurrenceOverrides without a recurrenceRule sufficient? Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --a7ae25462a1c4ed2be66449e4ce631e2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
iMIP (RFC6047) messages can contain iTIP (RFC5546) files w= hich refer to just a single recurrence of a full event.

J= SCalendar doesn't have an easy way to specify this kind of "orphan" even= t, I'm considering that maybe it looks like this:

BASE EV= ENT:

   {
      "duration" : "PT1H",
      "recurrenceR= ule" : {
   &n= bsp;     "frequency" : "monthly"
      },
      "start" : "2= 016-01-01T13:00:00",
 &n= bsp;    "timeZone" : "Europe/Vienna",
      "title" : "foo",<= br>
     = ; "uid" : "89eee195-600b-423b-b3a6-52b3a420e556",
      [...]
   }

OVERRIDE:
=

   {
&n= bsp;     "recurrenceOverrides": {
        "2016-03-01T13= :00:00": {
    = ;      "duration" : "PT2H",
          "start" = : "2016-03-01T13:00:00",
&nbs= p;         "timeZone" : "Europe/Vienna",
          "title" : "longfoo",
&n= bsp;         [...]
     &nbs= p;  },
   = ;   },
  =     "uid" : "89eee195-600b-423b-b3a6-52b3a420e556",
   }

COMBINED EVENT:

<= div style=3D"font-family:Arial;">   {
      "duration" : "PT1H",
      "recurren= ceOverrides": {
  &= nbsp;     "2016-03-01T13:00:00": {
          "= duration" : "PT2H",
 &nb= sp;        "title" : "longfoo",
        },
=
    &n= bsp; },
   &nb= sp;  "recurrenceRule" : {
&n= bsp;        "frequency" : "monthly"
     = },
    &= nbsp; "start" : "2016-01-01T13:00:00",
      "timeZone" : "Europe/Vienna",
     = "title" : "foo",
  = ;    "uid" : "89eee195-600b-423b-b3a6-52b3a420e556",
<= /div>
      [.= ..]
   }
<= div style=3D"font-family:Arial;">

<= /div>
WHERE [...] is all the other prop= erties.  They have to be duplicated inside the recurrenceOverride w= hen it's orphaned, because we don't have the parent event to refer to.

I THINK this format is sufficient for representing a singl= e recurrence, but let me know if you think I'm missing something.  = Should this have a separate @type key to tell you that it's an orphan or= is the presence of recurrenceOverrides without a recurrenceRule suffici= ent?

Bron.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com
=


--a7ae25462a1c4ed2be66449e4ce631e2-- From nobody Wed May 1 18:30:18 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63F612006D for ; Wed, 1 May 2019 18:30:16 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=dk09teG4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KeI5vBYh 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 15kp_K6pwGnq for ; Wed, 1 May 2019 18:30:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0446412006A for ; Wed, 1 May 2019 18:30:14 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 13B2D23176 for ; Wed, 1 May 2019 21:30:14 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 01 May 2019 21:30:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=rsA+EBN YTVhElRqczvHveK1bgelJ/9T+bq50l3fjbWk=; b=dk09teG4ITzhmpsxtwbEEL7 4vauqx7Mch7JmK3wXgQ14Ax5BFCOmq9ia1A7IKmP2DUqe7RUgq2oTTLNGnjOxOkU 9NGIkci56qeBkTSWUsX6Ds8UD70IK/QGMKmoISqIKFb+2MuUo1nzw8C04ePq6yY8 Ea+IuGD44Rwd634Qi5SWneOiYuy4EezEwFLiyqQejoXTzN/6fEXWJ4iNPGFgbGF+ nDs8BcBKeQiTJmumIpQg7mXw81RmbkS/rQb1kbHsmamMfDluZh/MbnH4muvXGdWp Y55tNCpgARyrGrcVFZrPl0UtN9399oBjXw+9eVrcfQt0jSZjoXL57d8r9GjY0hw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=rsA+EB NYTVhElRqczvHveK1bgelJ/9T+bq50l3fjbWk=; b=KeI5vBYh5FwaXtuTRcKzXe 5SDCMhZgoHgA7RNN6+Fo2rVF197stixSg7m/fI9hMfkBfQ0suXr206HbYW803wJs N61JP9bpMKWfkyERut4NyQJkugDrmNGQWuE8sNlFbxTnjeOXadllVplAEHyv6msM ZLWevyOFRKmwYQ02rKNX/n8mBhrgAjqNzozCbhIIw4cvlHg1C/mht8qGErUoWX37 UgmffptDF+pRkcdw8GIQPzXNFSxefrSlxiD66nUPW6khOtnl1jXtwnkQ77mkYnOf RJFwDQjev8jw7tVjtYEcH0bJcazHvxErBZ4BoX+Wm1iWDx5lH8yN9coSTBNbm04g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieekgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepnhgvih hljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67675211C2; Wed, 1 May 2019 21:30:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <7023a66f-b073-4330-9493-52453e888091@beta.fastmail.com> In-Reply-To: <49ae6861-d60c-45fa-9b8f-ee8c2bae8b7d@www.fastmail.com> References: <49ae6861-d60c-45fa-9b8f-ee8c2bae8b7d@www.fastmail.com> Date: Wed, 01 May 2019 21:30:13 -0400 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f6462e5eb650457892257ba5f3ff3d97 Archived-At: Subject: Re: [calsify] JSCalendar format for individual recurrences X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 01:30:17 -0000 --f6462e5eb650457892257ba5f3ff3d97 Content-Type: text/plain No, this isn't quite right. The following properties are non-optional at the top-level: * @type * uid * updated * start Further, the following cannot be overridden in recurrenceOverrides: * @type * uid * relatedTo * prodId * method * isAllDay * recurrenceRule * recurrenceOverrides * replyTo So then I think we have two options for representing orphaned single occurrences for iTIP. The first option is to define a new property (maybe `occurrenceId` or `recurrenceId`) which denotes this is an occurrence, and then represent it like a non-recurring event; this is similar to iCalendar. The value of this property would be the key used in `recurrenceOverrides` in the original event, i.e. the same as the start time of the occurrence unless this is overridden. The other option is a bit more complicated: 1. Remove any `recurrenceRule` property. 2. Remove any `recurrenceOverride` entries for other occurrences. 3. Move/merge any top-level property that may be overridden into the recurrence override. 4. Either change the top-level `start` to match the recurrence override id, or add an entry to `recurrenceOverrides` to delete the original start. The advantage of option (2) is that you can represent being invited to multiple individual occurrences of the master event in a single object; indeed, this is probably the format I would choose for storing the event in if my backend was storing JSCalendar. However for iTIP purposes *I think option (1) is much simpler and probably the better choice*. Example of option 2; original event: { "@type": "jsevent", "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f", "updated": "2019-05-01T00:00:00Z", "start": "2019-05-06T09:00:00", "duration": "PT1H0M0S", "timeZone": "Australia/Melbourne", "title": "The Meeting", "description": "The Notes.", "locations": { "1": { "name": "The Location" } }, "isAllDay": false, "recurrenceRule": { "frequency": "weekly" }, "recurrenceOverrides": { "2019-05-13T09:00:00": { "participants/c3BlY2lhbEBleGFtcGxlLmNvbQ": { "name": "", "email": "special@example.com", "sendTo": { "imip": "mailto:special@example.com" }, "kind": "individual", "roles": { "attendee": true }, "participationStatus": "needs-action", "expectReply": true } } }, "status": "confirmed", "replyTo": { "imip": "mailto:me@example.com" }, "participants": { "dXNlckBnbWFpbC5jb20": { "name": "My Name", "email": "me@example.com", "sendTo": { "imip": "mailto:me@example.com" }, "kind": "individual", "roles": { "attendee": true, "owner": true }, "participationStatus": "accepted", "expectReply": false }, "amFuZUBleGFtcGxlLmNvbQ": { "name": "", "email": "regular@example.com", "sendTo": { "imip": "mailto:regular@example.com" }, "kind": "individual", "roles": { "attendee": true }, "participationStatus": "needs-action", "expectReply": true } } } and representation of single override, for special@example.com: { "@type": "jsevent", "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f", "updated": "2019-05-01T00:00:00Z", "start": "2019-05-06T09:00:00", "isAllDay": false, "recurrenceOverrides": { "2019-05-13T09:00:00": { "duration": "PT1H0M0S", "timeZone": "Australia/Melbourne", "title": "The Meeting", "description": "The Notes.", "locations": { "1": { "name": "The Location" } }, "status": "confirmed", "participants": { "dXNlckBnbWFpbC5jb20": { "name": "My Name", "email": "me@example.com", "sendTo": { "imip": "mailto:me@example.com" }, "kind": "individual", "roles": { "attendee": true, "owner": true }, "participationStatus": "accepted", "expectReply": false }, "amFuZUBleGFtcGxlLmNvbQ": { "name": "", "email": "regular@example.com", "sendTo": { "imip": "mailto:regular@example.com" }, "kind": "individual", "roles": { "attendee": true }, "participationStatus": "needs-action", "expectReply": true }, c3BlY2lhbEBleGFtcGxlLmNvbQ": { "name": "", "email": "special@example.com", "sendTo": { "imip": "mailto:special@example.com" }, "kind": "individual", "roles": { "attendee": true }, "participationStatus": "needs-action", "expectReply": true } } } }, "replyTo": { "imip": "mailto:me@example.com" } } Neil. --f6462e5eb650457892257ba5f3ff3d97 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
No, this i= sn't quite right. The following properties are non-optional at the top-l= evel:

  • @type
  • uid
  • upda= ted
  • start

Further, the foll= owing cannot be overridden in recurrenceOverrides:

      • @type
      • uid
      • relatedTo=
      • prodId
      • method
      • isAllDay
      • = recurrenceRule
      • recurrenceOverrides
      • replyTo

      So then I think we have two options for repr= esenting orphaned single occurrences for iTIP. The first option is to de= fine a new property (maybe occurrenceId or recurrenceId) whi= ch denotes this is an occurrence, and then represent it like a non-recur= ring event; this is similar to iCalendar. The value of this property wou= ld be the key used in recurrenceOverrides in the original event, i= .e. the same as the start time of the occurrence unless this is overridd= en.

      The other option is a bit more complica= ted:
      1. Remove any recurrenceRule property.
      2. = Remove any recurrenceOverride entries for other occurrences.
      3. Move/merge any top-level property that may be overridden into the= recurrence override.
      4. Either change the top-level start to match the recurrence override id, or add an entry to rec= urrenceOverrides to delete the original start.
      =
      The advantage of option (2) is that you can represent bei= ng invited to multiple individual occurrences of the master event in a s= ingle object; indeed, this is probably the format I would choose for sto= ring the event in if my backend was storing JSCalendar. However for iTIP= purposes I think option (1) is much simpler and probably the better = choice.

      Example of option 2; original e= vent:

      {
        "@type": "jsevent",
        "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f",
        "updated": "2019-05-01T00:00:00Z",
        "start": "2019-05-06T09:00:00",
        "duration": "PT1H0M0S",
        "timeZone": "Australia/Melbourne",
        "title": "The Meeting",
        "description": "The Notes.",
        "locations": {
          "1": {
            "name": "The Location"
          }
        },
        "isAllDay": false,
        "recurrenceRule": {
          "frequency": "weekly"
        },
        "recurrenceOverrides": {
          "2019-05-13T09:00:00": {
            "participants/c3BlY2lhbEBleGFtcGxlLmNvbQ": {
              "name": "",
              "email": "special@example=
      .com",
              "sendTo": {
                "imip": "mailto:special=
      @example.com"
              },
              "kind": "individual",
              "roles": {
                "attendee": true
              },
              "participationStatus": "needs-action",
              "expectReply": true
            }
          }
        },
        "status": "confirmed",
        "replyTo": {
          "imip": "mailto:me@example.com=
      "
        },
        "participants": {
          "dXNlckBnbWFpbC5jb20": {
            "name": "My Name",
            "email": "me@example.com",
            "sendTo": {
              "imip": "mailto:me@example.com=
      "
            },
            "kind": "individual",
            "roles": {
              "attendee": true,
              "owner": true
            },
            "participationStatus": "accepted",
            "expectReply": false
          },
          "amFuZUBleGFtcGxlLmNvbQ": {
            "name": "",
            "email": "regular@example.c=
      om",
            "sendTo": {
              "imip": "mailto:regular@e=
      xample.com"
            },
            "kind": "individual",
            "roles": {
              "attendee": true
            },
            "participationStatus": "needs-action",
            "expectReply": true
          }
        }
      }

      and representation of single override, fo= r special@example.com:

      {
        "@type": "jsevent",
        "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f",
        "updated": "2019-05-01T00:00:00Z",
        "start": "2019-05-06T09:00:00",
        "isAllDay": false,
        "recurrenceOverrides": {
          "2019-05-13T09:00:00": {
            "duration": "PT1H0M0S",
            "timeZone": "Australia/Melbourne",
            "title": "The Meeting",
            "description": "The Notes.",
            "locations": {
              "1": {
                "name": "The Location"
              }
            },
            "status": "confirmed",
            "participants": {
              "dXNlckBnbWFpbC5jb20": {
                "name": "My Name",
                "email": "me@example.com=
      ",
                "sendTo": {
                  "imip": "mailto:me@example=
      .com"
                },
                "kind": "individual",
                "roles": {
                  "attendee": true,
                  "owner": true
                },
                "participationStatus": "accepted",
                "expectReply": false
              },
              "amFuZUBleGFtcGxlLmNvbQ": {
                "name": "",
                "email": "regular@examp=
      le.com",
                "sendTo": {
                  "imip": "mailto:regul=
      ar@example.com"
                },
                "kind": "individual",
                "roles": {
                  "attendee": true
                },
                "participationStatus": "needs-action",
                "expectReply": true
              },
              c3BlY2lhbEBleGFtcGxlLmNvbQ": {
                "name": "",
                "email": "special@examp=
      le.com",
                "sendTo": {
                  "imip": "mailto:speci=
      al@example.com"
                },
                "kind": "individual",
                "roles": {
                  "attendee": true
                },
                "participationStatus": "needs-action",
                "expectReply": true
              }
            }
          }
        },
        "replyTo": {
          "imip": "mailto:me@example.com=
      "
        }
      }

      Neil.
      --f6462e5eb650457892257ba5f3ff3d97-- From nobody Thu May 2 06:08:34 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEEA12033C for ; Thu, 2 May 2019 06:08:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 yGCLqhQE7UeY for ; Thu, 2 May 2019 06:08:29 -0700 (PDT) Received: from mailrelay1-1.pub.mailoutpod1-cph3.one.com (mailrelay1-1.pub.mailoutpod1-cph3.one.com [46.30.210.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F60120331 for ; Thu, 2 May 2019 06:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=+WixDAgNuSKG4QlnlGgKX5saLJksXUYz5n3su5b2koE=; b=uWQdpd5Wj7ynt/b1NH+eQlpQ8vmz7NR0d9p8yLdORLrTBHvA0JqZBlCOkhWzUsdqwsYDbA25dmTpv 6X1O5rvOdJfpedc5vYXwP/jHGNvod16QORCOoioBBw5PZSgldIpUvY4NjHB31NbqLnZJkT7DA32CiG SfVbrPcu3GgkKF04= X-HalOne-Cookie: d4dfe839795c609678c1fe579b9999011d5c6fce X-HalOne-ID: 5e36bfe2-6cdb-11e9-b614-d0431ea8a283 Received: from smtp.dmfs.org (unknown [2003:5f:6e16:2f00:201:2eff:fe40:2624]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 5e36bfe2-6cdb-11e9-b614-d0431ea8a283; Thu, 02 May 2019 13:08:24 +0000 (UTC) Received: from boss.localdomain (p3EE0495D.dip0.t-ipconnect.de [62.224.73.93]) by smtp.dmfs.org (Postfix) with ESMTPSA id 721BD339 for ; Thu, 2 May 2019 15:08:24 +0200 (CEST) To: calsify@ietf.org References: <49ae6861-d60c-45fa-9b8f-ee8c2bae8b7d@www.fastmail.com> <7023a66f-b073-4330-9493-52453e888091@beta.fastmail.com> From: Marten Gajda Message-ID: Date: Thu, 2 May 2019 15:08:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <7023a66f-b073-4330-9493-52453e888091@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------4EAF924623106475060FFB44" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar format for individual recurrences X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 13:08:33 -0000 This is a multi-part message in MIME format. --------------4EAF924623106475060FFB44 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Why would you move/merge the non-overridden properties from the top level event into the override? That doesn't seem to make much sense, especially considering the fact that there may be more than one override you're invited to. For consistency I strongly prefer option #2. I think your example lacks the result of the 4th step, i.e. it would be interpreted as two instances. Marten > No, this isn't quite right. The following properties are non-optional > at the top-level: > > * @type > * uid > * updated > * start > > > Further, the following cannot be overridden in recurrenceOverrides: > > * @type > * uid > * relatedTo > * prodId > * method > * isAllDay > * recurrenceRule > * recurrenceOverrides > * replyTo > > > So then I think we have two options for representing orphaned single > occurrences for iTIP. The first option is to define a new property > (maybe |occurrenceId| or |recurrenceId|) which denotes this is an > occurrence, and then represent it like a non-recurring event; this is > similar to iCalendar. The value of this property would be the key used > in |recurrenceOverrides| in the original event, i..e. the same as the > start time of the occurrence unless this is overridden. > > The other option is a bit more complicated: > > 1. Remove any |recurrenceRule| property. > 2. Remove any |recurrenceOverride| entries for other occurrences. > 3. Move/merge any top-level property that may be overridden into the > recurrence override. > 4. Either change the top-level |start| to match the recurrence > override id, or add an entry to |recurrenceOverrides| to delete > the original start. > > > The advantage of option (2) is that you can represent being invited to > multiple individual occurrences of the master event in a single > object; indeed, this is probably the format I would choose for storing > the event in if my backend was storing JSCalendar. However for iTIP > purposes *I think option (1) is much simpler and probably the better > choice*. > > Example of option 2; original event: > > { > "@type": "jsevent", > "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f", > "updated": "2019-05-01T00:00:00Z", > "start": "2019-05-06T09:00:00", > "duration": "PT1H0M0S", > "timeZone": "Australia/Melbourne", > "title": "The Meeting", > "description": "The Notes.", > "locations": { > "1": { > "name": "The Location" > } > }, > "isAllDay": false, > "recurrenceRule": { > "frequency": "weekly" > }, > "recurrenceOverrides": { > "2019-05-13T09:00:00": { > "participants/c3BlY2lhbEBleGFtcGxlLmNvbQ": { > "name": "", > "email": "special@example..com ", > "sendTo": { > "imip": "mailto:special@example.com " > }, > "kind": "individual", > "roles": { > "attendee": true > }, > "participationStatus": "needs-action", > "expectReply": true > } > } > }, > "status": "confirmed", > "replyTo": { > "imip": "mailto:me@example.com " > }, > "participants": { > "dXNlckBnbWFpbC5jb20": { > "name": "My Name", > "email": "me@example.com ", > "sendTo": { > "imip": "mailto:me@example.com " > }, > "kind": "individual", > "roles": { > "attendee": true, > "owner": true > }, > "participationStatus": "accepted", > "expectReply": false > }, > "amFuZUBleGFtcGxlLmNvbQ": { > "name": "", > "email": "regular@example.com ", > "sendTo": { > "imip": "mailto:regular@example.com " > }, > "kind": "individual", > "roles": { > "attendee": true > }, > "participationStatus": "needs-action", > "expectReply": true > } > } > } > > and representation of single override, for special@example.com > : > > { > "@type": "jsevent", > "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f", > "updated": "2019-05-01T00:00:00Z", > "start": "2019-05-06T09:00:00", > "isAllDay": false, > "recurrenceOverrides": { > "2019-05-13T09:00:00": { > "duration": "PT1H0M0S", > "timeZone": "Australia/Melbourne", > "title": "The Meeting", > "description": "The Notes.", > "locations": { > "1": { > "name": "The Location" > } > }, > "status": "confirmed", > "participants": { > "dXNlckBnbWFpbC5jb20": { > "name": "My Name", > "email": "me@example.com ", > "sendTo": { > "imip": "mailto:me@example..com " > }, > "kind": "individual", > "roles": { > "attendee": true, > "owner": true > }, > "participationStatus": "accepted", > "expectReply": false > }, > "amFuZUBleGFtcGxlLmNvbQ": { > "name": "", > "email": "regular@example.com ", > "sendTo": { > "imip": "mailto:regular@example.com " > }, > "kind": "individual", > "roles": { > "attendee": true > }, > "participationStatus": "needs-action", > "expectReply": true > }, > c3BlY2lhbEBleGFtcGxlLmNvbQ": { > "name": "", > "email": "special@example.com ", > "sendTo": { > "imip": "mailto:special@example.com " > }, > "kind": "individual", > "roles": { > "attendee": true > }, > "participationStatus": "needs-action", > "expectReply": true > } > } > } > }, > "replyTo": { > "imip": "mailto:me@example.com " > } > } > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------4EAF924623106475060FFB44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Why would you move/merge the non-overridden properties from the top level event into the override? That doesn't seem to make much sense, especially considering the fact that there may be more than one override you're invited to.

      For consistency I strongly prefer option #2.

      I think your example lacks the result of the 4th step, i.e. it would be interpreted as two instances.

      Marten


      No, this isn't quite right. The following properties are non-optional at the top-level:

      • @type
      • uid
      • updated
      • start

      Further, the following cannot be overridden in recurrenceOverrides:

      • @type
      • uid
      • relatedTo
      • prodId
      • method
      • isAllDay
      • recurrenceRule
      • recurrenceOverrides
      • replyTo

      So then I think we have two options for representing orphaned single occurrences for iTIP. The first option is to define a new property (maybe occurrenceId or recurrenceId) which denotes this is an occurrence, and then represent it like a non-recurring event; this is similar to iCalendar. The value of this property would be the key used in recurrenceOverrides in the original event, i..e. the same as the start time of the occurrence unless this is overridden.

      The other option is a bit more complicated:
      1. Remove any recurrenceRule property.
      2. Remove any recurrenceOverride entries for other occurrences.
      3. Move/merge any top-level property that may be overridden into the recurrence override.
      4. Either change the top-level start to match the recurrence override id, or add an entry to recurrenceOverrides to delete the original start.

      The advantage of option (2) is that you can represent being invited to multiple individual occurrences of the master event in a single object; indeed, this is probably the format I would choose for storing the event in if my backend was storing JSCalendar. However for iTIP purposes I think option (1) is much simpler and probably the better choice.

      Example of option 2; original event:

      {
        "@type": "jsevent",
        "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f",
        "updated": "2019-05-01T00:00:00Z",
        "start": "2019-05-06T09:00:00",
        "duration": "PT1H0M0S",
        "timeZone": "Australia/Melbourne",
        "title": "The Meeting",
        "description": "The Notes.",
        "locations": {
          "1": {
            "name": "The Location"
          }
        },
        "isAllDay": false,
        "recurrenceRule": {
          "frequency": "weekly"
        },
        "recurrenceOverrides": {
          "2019-05-13T09:00:00": {
            "participants/c3BlY2lhbEBleGFtcGxlLmNvbQ": {
              "name": "",
              "email": "special@example..com",
              "sendTo": {
                "imip": "mailto:special@example.com"
              },
              "kind": "individual",
              "roles": {
                "attendee": true
              },
              "participationStatus": "needs-action",
              "expectReply": true
            }
          }
        },
        "status": "confirmed",
        "replyTo": {
          "imip": "mailto:me@example.com"
        },
        "participants": {
          "dXNlckBnbWFpbC5jb20": {
            "name": "My Name",
            "email": "me@example.com",
            "sendTo": {
              "imip": "mailto:me@example.com"
            },
            "kind": "individual",
            "roles": {
              "attendee": true,
              "owner": true
            },
            "participationStatus": "accepted",
            "expectReply": false
          },
          "amFuZUBleGFtcGxlLmNvbQ": {
            "name": "",
            "email": "regular@example.com",
            "sendTo": {
              "imip": "mailto:regular@example.com"
            },
            "kind": "individual",
            "roles": {
              "attendee": true
            },
            "participationStatus": "needs-action",
            "expectReply": true
          }
        }
      }
      

      and representation of single override, for special@example.com:

      {
        "@type": "jsevent",
        "uid": "7722a0b8-1b39-431c-88df-b03f1096b81f",
        "updated": "2019-05-01T00:00:00Z",
        "start": "2019-05-06T09:00:00",
        "isAllDay": false,
        "recurrenceOverrides": {
          "2019-05-13T09:00:00": {
            "duration": "PT1H0M0S",
            "timeZone": "Australia/Melbourne",
            "title": "The Meeting",
            "description": "The Notes.",
            "locations": {
              "1": {
                "name": "The Location"
              }
            },
            "status": "confirmed",
            "participants": {
              "dXNlckBnbWFpbC5jb20": {
                "name": "My Name",
                "email": "me@example.com",
                "sendTo": {
                  "imip": "mailto:me@example..com"
                },
                "kind": "individual",
                "roles": {
                  "attendee": true,
                  "owner": true
                },
                "participationStatus": "accepted",
                "expectReply": false
              },
              "amFuZUBleGFtcGxlLmNvbQ": {
                "name": "",
                "email": "regular@example.com",
                "sendTo": {
                  "imip": "mailto:regular@example.com"
                },
                "kind": "individual",
                "roles": {
                  "attendee": true
                },
                "participationStatus": "needs-action",
                "expectReply": true
              },
              c3BlY2lhbEBleGFtcGxlLmNvbQ": {
                "name": "",
                "email": "special@example.com",
                "sendTo": {
                  "imip": "mailto:special@example.com"
                },
                "kind": "individual",
                "roles": {
                  "attendee": true
                },
                "participationStatus": "needs-action",
                "expectReply": true
              }
            }
          }
        },
        "replyTo": {
          "imip": "mailto:me@example.com"
        }
      }
      

      Neil.

      _______________________________________________
      calsify mailing list
      calsify@ietf.org
      https://www.ietf.org/mailman/listinfo/calsify
      
      -- 
      Marten Gajda
      CEO
      
      dmfs GmbH
      Schandauer Straße 34
      01309 Dresden
      GERMANY
      
      phone: +49 177 4427167
      email: marten@dmfs.org
      
      Managing Director: Marten Gajda
      Registered address: Dresden
      Registered No.: AG Dresden HRB 34881
      VAT Reg. No.: DE303248743
      --------------4EAF924623106475060FFB44-- From nobody Thu May 2 07:20:57 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ACC12039A for ; Thu, 2 May 2019 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 twEF_RIrLsMf for ; Thu, 2 May 2019 07:20:54 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2E120392 for ; Thu, 2 May 2019 07:20:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6A0E83009CBF45; Thu, 2 May 2019 10:20:53 -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 tyEv2NcITDHo; Thu, 2 May 2019 10:20:52 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 48A833009CBF34; Thu, 2 May 2019 10:20:52 -0400 (EDT) Date: Thu, 02 May 2019 10:20:50 -0400 From: Cyrus Daboo To: Neil Jenkins , calsify@ietf.org Message-ID: In-Reply-To: <7023a66f-b073-4330-9493-52453e888091@beta.fastmail.com> References: <49ae6861-d60c-45fa-9b8f-ee8c2bae8b7d@www.fastmail.com> <7023a66f-b073-4330-9493-52453e888091@beta.fastmail.com> 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=2186 Archived-At: Subject: Re: [calsify] JSCalendar format for individual recurrences X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 14:20:56 -0000 Hi Neil, --On May 1, 2019 at 9:30:13 PM -0400 Neil Jenkins wrote: > No, this isn't quite right. The following properties are non-optional at > the top-level: > > * @type > * uid > * updated > * start > > Further, the following cannot be overridden in recurrenceOverrides: > > * @type > * uid > * relatedTo > * prodId > * method > * isAllDay > * recurrenceRule > * recurrenceOverrides > * replyTo > > So then I think we have two options for representing orphaned single > occurrences for iTIP. The first option is to define a new property (maybe > `occurrenceId` or `recurrenceId`) which denotes this is an occurrence, > and then represent it like a non-recurring event; this is similar to > iCalendar. The value of this property would be the key used in > `recurrenceOverrides` in the original event, i.e. the same as the start > time of the occurrence unless this is overridden. Please note that iTIP (as defined by 5546) overrides the "required" properties of base iCalendar (see all the tables in that spec which indicate new requirements for properties in iTIP messages). There are some good reasons for that (e.g., for a CANCEL message you really don't need to send much more than enough information to uniquely identify the instance being cancelled - e.g. no need for "start"). Of course the question arises as to whether you want to use iTIP as the basis for JSCalendar scheduling messages, or whether you want to do something different. There are well known issues with parts of iTIP that we attempted to correct with the last update, but I don't think we really managed to do that. I think it makes sense for this group to re-think scheduling in its entirety to see if a cleaner, simpler solution is viable, fitting in with the overall approach for JSCalendar and jcal etc. I am not sure whether that belongs as part of the JMAP re-charter or something for this WG. In any case, there is a need to store individual recurrences in calendar stores once they have been delivered by iTIP and yes, those must conform to the property requirements of JSCalendar since they must be valid JSCalendar objects. -- Cyrus Daboo From nobody Thu May 2 08:00:03 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 414A41203A0; Thu, 2 May 2019 07:59:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155680919316.24781.10248607705478645038@ietfa.amsl.com> Date: Thu, 02 May 2019 07:59:53 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-13.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 14:59:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-13.txt Pages : 51 Date : 2019-05-02 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative to the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-13 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 2 08:03:43 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE021200CE; Thu, 2 May 2019 08:03:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155680941264.24756.15511384462477061094@ietfa.amsl.com> Date: Thu, 02 May 2019 08:03:32 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-icalendar-00.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 15:03:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: Converting from and to iCalendar Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-icalendar-00.txt Pages : 12 Date : 2019-05-02 Abstract: This document provides an informational guideline for converting JSCalendar from and to iCalendar. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar-00 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-icalendar-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 2 08:06:45 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CCD1203C7 for ; Thu, 2 May 2019 08:06:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=QziGYvr0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NnTgtwSv 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 MT995sd2g7Of for ; Thu, 2 May 2019 08:06:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38321203BD for ; Thu, 2 May 2019 08:06:36 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8DBED25C0D for ; Thu, 2 May 2019 11:06:35 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 02 May 2019 11:06:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=8zpjjlO9LHaCJXFfcJAZoA1Fa7pzTs4DgYLZDnW wxuA=; b=QziGYvr08ihm9Ak0k7XGV0/Dxnhoz3RbUy/i0cmWejdiib837TFG0Pb TioxVgfkFUeP0asgCkWcXamu9ccwGcF16Mqy+zgv+btOeAovr5l5D7sUR+b6JvCR N23bb4od9FVamBrA7Y5ITVrPnTPOujgPJ5GW/KdX7YBB7vp2VGLRn6F5/+mw4Cx+ X229KlsHKEVsu6//DpSLDO1YExFVka2gqwqTtMw4ZYRxybh67zmjSkfsPB6CwdB0 EHXxhwZJXtVLyisSrYP75OK7XpkebGGlu18ziepaEtN0FEA5JIAUTfL8rnwJ5jvq fAcUByhV+UhimzJkeeIQr8v9clhmAlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=8zpjjlO9LHaCJXFfcJAZoA1Fa7pzT s4DgYLZDnWwxuA=; b=NnTgtwSvYOdlKhkDv++z4zS23sADP3TrVBtyJJuiOpeLf YJbyklKxSPZIX6zkePh6Y2h4RVXw636RcLyCHkvazGKLDSbB6TrqQ4cYiKcbHq8B l5grUdn5S0zS5Qv99mBjxU6AZ+GrzJCsWKDP8/Mzyh1Ymhq/grVH0P6BiTEnf1WP Sv56F4oBF96xKGl5rjfTYE3rxNM5Pq+2N15XSNrIOVsMwCqRxa4RN7gRyypV1AOh x8bTlTMCSAsEG5vkCVul1fFTjZ+pdJpie9pdIxyDNiUGmrYFWyb2BTjustI7gjd4 yhxvuRxjkrC6UIhPGpJDCAbmsecT+VkZdWuw0H+5Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieelgdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7273F211C2; Thu, 2 May 2019 11:06:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: Date: Thu, 02 May 2019 11:06:34 -0400 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=fd5c4f24ca454a46b65dd30340ab6516 Archived-At: Subject: [calsify] Updated JSCalendar RFC draft version 13 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 15:06:41 -0000 --fd5c4f24ca454a46b65dd30340ab6516 Content-Type: text/plain Hi All, I have just submitted an updated version of the JSCalendar RFC draft. *Main changes:* * Split RFC draft into core specification (version 13) and an informational guideline how to map JSCalendar and iCalendar. * Updated core spec: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ * New mapping guideline: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar/ *Other changes:* * renamed Location{rel} property to Location{relativeTo} * defined OffsetTrigger to allow for custom alert triggers As always, we look forward to your feedback. Cheers, Robert --fd5c4f24ca454a46b65dd30340ab6516 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
      Hi All,

      I have just submitted an updated version of t= he JSCalendar RFC draft.

      Main changes:

      Other changes:
      • renamed Location{rel} property to Location{relativeTo}
      • defined OffsetTrigger to allow for custom alert triggers
        <= /li>

      As always, we look forward to your feedback= .

      Cheers,
      Robert
      --fd5c4f24ca454a46b65dd30340ab6516-- From nobody Thu May 2 17:42:22 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2AF12011D for ; Thu, 2 May 2019 17:42:21 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=C/KJiM4a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tjMML+ou 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 8lEm6NfLNmAd for ; Thu, 2 May 2019 17:42:17 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E9812011C for ; Thu, 2 May 2019 17:42:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id F399C87A for ; Thu, 2 May 2019 20:42:16 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 02 May 2019 20:42:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=928WDCu c13rS7BXRJ7wHuxBD3eupdE8ES4OCEWdHx3Y=; b=C/KJiM4ar6rEp5DbkKJxJtD XtJ+fwl758ik3VH8c8Ok9NdmpG1Q+x486Fjn029TZTBF86L7m9M5+gpxfZn7mxH4 +HcmjjZnZ1fNxJBacAml8C3H9zilJ88gs9GuaCwysDstYE4wIBLOCAVnvC1hqqpl Igl8gpg4yx9SxcJVPW3Q99pWgCvK/Ml3fnBKYCtNcbhNAhdVCpWr4qPkPEBhORog CwID/a6CI6lM9/5OzYvcrLQ2LeCsnPwIH6VgaMXDI4tIOCe92UP8dLL6hYRIAXKy yRSKUF/QXGPta7mEzijr0rYEkendscY7+vjK7dGToA1q6bUwTGUjHx9me8PJt/Q= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=928WDC uc13rS7BXRJ7wHuxBD3eupdE8ES4OCEWdHx3Y=; b=tjMML+ouWsP+M622u1IwB3 FCZ5dMV2CClhc56uFb3g9qDVZqFV258/6kyroXgLc9gYLXGyPI7CgTbIaFPKG3bT 890WsyruCU7/5CNePhbNNiflxt8svTMM6VXsDvbI1nbIbKjTljFb793y28aW8V5n 5XWdwhvUjyC3ic/9GDKS4fgg5+G+zJDpK9FV+G/l2PqNQM4QRcE0DBpbrtiX1XYu jz8sUYIC8g9Q6LRnZDhMP9ArJDvnwCtTlBaolpe66DANmUKwX33CysffTjQkWvmw s+ElXPAcoPEC9zLjvaeR4XI2XCJPRanPFJATGc4nlvkaBXb8G/wxzUpDkbKn+fDA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjedtgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepnhgvih hljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 34567211C2; Thu, 2 May 2019 20:42:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <27e9d781-a6f2-4c43-9def-f817e69aca7c@beta.fastmail.com> In-Reply-To: References: <49ae6861-d60c-45fa-9b8f-ee8c2bae8b7d@www.fastmail.com> <7023a66f-b073-4330-9493-52453e888091@beta.fastmail.com> Date: Thu, 02 May 2019 20:42:15 -0400 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=7a8c43b448064c379fe975fcff9703a7 Archived-At: Subject: Re: [calsify] JSCalendar format for individual recurrences X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 00:42:21 -0000 --7a8c43b448064c379fe975fcff9703a7 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 2 May 2019, at 23:08, Marten Gajda wrote: > Why would you move/merge the non-overridden properties from the top le= vel event into the override? That doesn't seem to make much sense, espec= ially considering the fact that there may be more than one override you'= re invited to.=20 It's so you don't leak data that the organiser might expect to be hidden= from the user. e.g. If your regular event had a note "Top secret code i= s XXY, don't tell Bob" and then you invite Bob to one specific instance = of the event and override the note to be "Regular meeting, nothing to se= e here". Maybe it's being over-paranoid but the "right" thing to do I think is to= only expose the property values for the instance the user is invited to= . There are several different ways you could do this of course. > For consistency I strongly prefer option #2. I'm not convinced. I think for iTIP messages #option 1 is easier to hand= le. Another issue with #2: suppose you are invited to two different occu= rrences of a general recurring event. Does the iTIP version include the = data for both of the recurrences in a single object? The iCalendar versi= on will be two separate VEVENTs in two separate iTIP emails, so this is = awkward. But if you represent each one separately, how do you know the s= econd email is an invitation to a second instance, rather than updating = the data you received in the first email? Stepping back, there are two separate reasons for needing this represent= ation: 1. You receive an iCalendar iMIP message and want to translate it into = JSCalendar for a client; option #1 is a closer mapping to the iCalendar = here and seems much easier for the client to manage. The iCalendar doesn= 't have sufficient data to do option #2. 2. You want to send scheduling messages to another system. I don't thin= k we need to be in any rush with this, since iMIP messages will be neede= d for a long time to come for backwards compatibility, and as Cyrus poin= ts out I think it would be better to take our time and reassess whether = we can use the opportunity to improve on this process too. > I think your example lacks the result of the 4th step, i.e. it would b= e interpreted as two instances. You're right, sorry; the perils of editing it by hand! On Fri, 3 May 2019, at 00:20, Cyrus Daboo wrote: > Please note that iTIP (as defined by 5546) overrides the "required"=20= > properties of base iCalendar (see all the tables in that spec which=20= > indicate new requirements for properties in iTIP messages). Right, I think this would probably be more sensible than requiring a dum= my start value. > Of course the question arises as to whether you want to use iTIP as th= e=20 > basis for JSCalendar scheduling messages, or whether you want to do=20= > something different. There are well known issues with parts of iTIP th= at we=20 > attempted to correct with the last update, but I don't think we really= =20 > managed to do that. I think it makes sense for this group to re-think=20= > scheduling in its entirety to see if a cleaner, simpler solution is vi= able,=20 > fitting in with the overall approach for JSCalendar and jcal etc. I am= not=20 > sure whether that belongs as part of the JMAP re-charter or something = for=20 > this WG. This might be worthwhile. What I would like to see in the future is some= thing like this: * The initial invitation for an event is still sent out as an email. Fo= r backwards compatibility there will need to be a text/calendar part for= iMIP-understanding clients. But then after that we would add a JSCalend= ar part that newer clients would use instead; this would just be ignored= by older clients presuming they support multipart/alternative correctly= . * JSCalendar supports multiple "replyTo" mechanisms, so it could suppor= t both iMIP and AdvancedFutureSchedule=E2=84=A2=EF=B8=8F.=20 * If it's just an email client without an integrated calendar it might = support sending a basic RSVP via iMIP. But if it has a real calendar att= ached, it adds the event there and the RSVP is sent back via AdvancedFut= ureSchedule=E2=84=A2=EF=B8=8F, which also sets up some non-mail communic= ation channel (probably a secret URL) that allows updates to be sent for= *that event only*. So the organising calendar server can now keep the i= nvitee's copy of the event up-to-date when other people change RSVP etc.= without cluttering up the user's inbox and without the fragility of goi= ng via email. It's up to the user's calendar to decide how/whether to no= tify the user if the event changes, so the user gets to decide what's im= portant. (Maybe some users really do want to be emailed every time someo= ne else's RSVP status changes!) The nice thing about this is it =E2=80=9Dsolves=E2=80=9C the identity pr= oblem that has plagued us for years, by having the initial invitation st= ill go via email; it's up to the user how to route this into their calen= dar. Once there though, it can upgrade all future scheduling negotiation= for that event to another system. Because it's on a per-event basis, it= doesn't have the problem of =E2=80=9Dstealing=E2=80=9C ownership of a c= alendar (like for example we have with Google Calendar, where a user mov= es their email from G Suite to our platform but never receive any invita= tions sent from Google Calendar because it still thinks it owns their ca= lendar). > In any case, there is a need to store individual recurrences in calend= ar=20 > stores once they have been delivered by iTIP and yes, those must confo= rm to=20 > the property requirements of JSCalendar since they must be valid JSCal= endar=20 > objects. Agreed. But the interchange/scheduling format doesn't need to be the sam= e as the storage format. Neil. --7a8c43b448064c379fe975fcff9703a7 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
      On Thu, 2 = May 2019, at 23:08, Marten Gajda wrote:
      Why would you move/merge the non-overridden properties= from the top level event into the override? That doesn't seem to make much sense,= especially considering the fact that there may be more than one override you're invited to.

      It's so you don't leak data that the organiser might expect to be hid= den from the user. e.g. If your regular event had a note "Top secret cod= e is XXY, don't tell Bob" and then you invite Bob to one specific instan= ce of the event and override the note to be "Regular meeting, nothing to= see here".

      Maybe it's being over-paranoid = but the "right" thing to do I think is to only expose the property value= s for the instance the user is invited to. There are several different w= ays you could do this of course.

      For consistency I strongly prefer option #2.


      I'm not convinced. I think for iTIP m= essages #option 1 is easier to handle. Another issue with #2: suppose yo= u are invited to two different occurrences of a general recurring event.= Does the iTIP version include the data for both of the recurrences in a= single object? The iCalendar version will be two separate VEVENTs in tw= o separate iTIP emails, so this is awkward. But if you represent each on= e separately, how do you know the second email is an invitation to a sec= ond instance, rather than updating the data you received in the first em= ail?

      Stepping back, there are two separate = reasons for needing this representation:
      1. You receive an= iCalendar iMIP message and want to translate it into JSCalendar for a c= lient; option #1 is a closer mapping to the iCalendar here and seems muc= h easier for the client to manage. The iCalendar doesn't have sufficient= data to do option #2.
      2. You want to send scheduling messages = to another system. I don't think we need to be in any rush with this, si= nce iMIP messages will be needed for a long time to come for backwards c= ompatibility, and as Cyrus points out I think it would be better to take= our time and reassess whether we can use the opportunity to improve on = this process too.

      I think your example lacks the result of the 4th step, i.e.= it would be interpreted as two instances.

      You're right, sorry; the perils of editing it by hand!
      <= /div>

      On Fri, 3 May 2019, at 00:20, Cyrus Daboo = wrote:
      Please note that iTIP (as= defined by 5546) overrides the "required" 
      propertie= s of base iCalendar (see all the tables in that spec which 
      indicate new requirements for properties in iTIP messages).

      Right, I think this would probably = be more sensible than requiring a dummy start value.

      <= /div>
      Of course the question arises as to = whether you want to use iTIP as the 
      basis for JSCale= ndar scheduling messages, or whether you want to do 
      = something different. There are well known issues with parts of iTIP that= we 
      attempted to correct with the last update, but I= don't think we really 
      managed to do that. I think i= t makes sense for this group to re-think 
      scheduling = in its entirety to see if a cleaner, simpler solution is viable, 
      fitting in with the overall approach for JSCalendar and jca= l etc. I am not 
      sure whether that belongs as part of= the JMAP re-charter or something for 
      this WG.

      This might be worthwhile. What= I would like to see in the future is something like this:

      • The initial invitation for an event is still sent out= as an email. For backwards compatibility there will need to be a text/c= alendar part for iMIP-understanding clients. But then after that we woul= d add a JSCalendar part that newer clients would use instead; this would= just be ignored by older clients presuming they support multipart/alter= native correctly.
      • JSCalendar supports multiple "replyTo" mec= hanisms, so it could support both iMIP and AdvancedFutureSchedule=E2=84=A2= =EF=B8=8F.
      • If it's just an email client without an integrat= ed calendar it might support sending a basic RSVP via iMIP. But if it ha= s a real calendar attached, it adds the event there and the RSVP is sent= back via AdvancedFutureSchedule=E2=84=A2=EF=B8=8F, which also sets= up some non-mail communication channel (probably a secret URL) that all= ows updates to be sent for that event only. So the organising cal= endar server can now keep the invitee's copy of the event up-to-date whe= n other people change RSVP etc. without cluttering up the user's inbox a= nd without the fragility of going via email. It's up to the user's calen= dar to decide how/whether to notify the user if the event changes, so th= e user gets to decide what's important. (Maybe some users really do want= to be emailed every time someone else's RSVP status changes!)
      • <= /ul>

        The nice thing about this is it =E2=80=9Dsolves=E2= =80=9C the identity problem that has plagued us for years, by having the= initial invitation still go via email; it's up to the user how to route= this into their calendar. Once there though, it can upgrade all future = scheduling negotiation for that event to another system. Because it's on= a per-event basis, it doesn't have the problem of =E2=80=9Dstealing=E2=80= =9C ownership of a calendar (like for example we have with Google Calend= ar, where a user moves their email from G Suite to our platform but neve= r receive any invitations sent from Google Calendar because it still thi= nks it owns their calendar).

      In any case, there is a need to store individual recur= rences in calendar 
      stores once they have been delive= red by iTIP and yes, those must conform to 
      the prope= rty requirements of JSCalendar since they must be valid JSCalendar =
      objects.

      Agreed= . But the interchange/scheduling format doesn't need to be the same as t= he storage format.

      Neil.
      --7a8c43b448064c379fe975fcff9703a7-- From nobody Wed May 8 18:30:00 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E77120203 for ; Wed, 8 May 2019 18:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 6Mwl4OKPzxH4 for ; Wed, 8 May 2019 18:29:55 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9DA120248 for ; Wed, 8 May 2019 18:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tLgH73t3K00IeO7TJAA2yc+dcvjiAptRf9AZ5WoITs0=; b=CNsrvtXqxydEX3CHvDcXo7EqIoZoXkUZibq5ROwTM53bA3ZwUWDv2Ey956QzF37vfKwGFeYe+OkjbescxEyKEqfbA29Q3+qr6/d7c0YY+bsXfKR+K5Sn3wQhvHRA/iJFx778BcRPcFYKwr6/c6Oh107e25pGHawmnhdQwr2BiaA= Received: from DM6PR15MB3531.namprd15.prod.outlook.com (10.141.164.29) by DM6PR15MB2650.namprd15.prod.outlook.com (20.179.161.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.21; Thu, 9 May 2019 01:29:53 +0000 Received: from DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::891e:88e6:d635:4431]) by DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::891e:88e6:d635:4431%2]) with mapi id 15.20.1878.019; Thu, 9 May 2019 01:29:53 +0000 From: Daniel Migault To: "calsify@ietf.org" Thread-Topic: WGLC draft-ietf-calext-jscalendar AND draft-ietf-calext-jscalendar-icalendar Thread-Index: AdUGBpryT4riSeZOS0e6uBfj/R3AIg== Date: Thu, 9 May 2019 01:29:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [70.80.131.240] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a3892624-b4eb-4704-5897-08d6d41dd65a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM6PR15MB2650; x-ms-traffictypediagnostic: DM6PR15MB2650: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(396003)(346002)(376002)(199004)(189003)(53936002)(44832011)(33656002)(486006)(476003)(66446008)(73956011)(76116006)(66946007)(66476007)(64756008)(66556008)(7736002)(7696005)(2501003)(99286004)(71200400001)(2351001)(9686003)(4744005)(86362001)(5660300002)(52536014)(478600001)(26005)(316002)(966005)(4743002)(14454004)(186003)(790700001)(256004)(14444005)(25786009)(71190400001)(66066001)(8676002)(81166006)(1730700003)(9326002)(81156014)(6506007)(102836004)(8936002)(5640700003)(55016002)(6306002)(54896002)(6436002)(74316002)(68736007)(2906002)(6916009)(3846002)(6116002)(564094006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2650; H:DM6PR15MB3531.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6WysRCLXSqyhneo3BUu3A9W5mw+9/8nhy11oDy0u85JKBlB/RbA7+TMHfUVfVNxEgmjtkJWtXecDf26I0taYcLmOE94e+rz3ZBYLwJhC3KR75k0pSXczJ1DBlMpTo6GGrD69Hg/60i9b3ZQIOyy6rYC1A9NbaoeABVeNxMpgyqSPJvlLH0DhCh/bXlHY+qaSTAeqwwDmz6dc/DMVBwuUEIRx3+7h8nQF2VTaN8G2njXSPJK8Ih2tzLjvyU8ZecH7km1P76Cl8EpfzDwb2ajnF0i/3uQuFk4BDyj5U3lfSSEKwHs4UX9LMWb72EzUnwJQiwtdDL5F12aS/J6w+oRi6CZ+4+CTK5T4CJScKthausUQHN9LDUiNtu/gpb0KlQJ+VD2thaLONqDzib72uX45ABCiP/ywugRCNd2+H6yCe3M= Content-Type: multipart/alternative; boundary="_000_DM6PR15MB35316FC8613A0A9D1DF5C142E3330DM6PR15MB3531namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3892624-b4eb-4704-5897-08d6d41dd65a X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 01:29:53.3638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2650 Archived-At: Subject: [calsify] WGLC draft-ietf-calext-jscalendar AND draft-ietf-calext-jscalendar-icalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 01:29:58 -0000 --_000_DM6PR15MB35316FC8613A0A9D1DF5C142E3330DM6PR15MB3531namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This email starts a WGLC for the two following documents: draft-ietf-calext= -jscalendar [1] and draft-ietf-calext-jscalendar-icalendar [2]. In response to discussion in Prague draft-ietf-calext-jscalendar was split = in [1] and [2]. Their content is meant to be close to the same. As the ori= ginal document was ready for working group last call, the WGLC runs for the= two documents [1] and [2]. Please review carefully the two documents and = provide your feedback/support on the mailing list. The WGLC ends on May 22 2019. Yours, Bron and Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ [2] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar= / --_000_DM6PR15MB35316FC8613A0A9D1DF5C142E3330DM6PR15MB3531namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Hi,

       

      This email starts a WGLC for the two following do= cuments: draft-ietf-calext-jscalendar [1] and draft-ietf-calext-jscalendar-= icalendar [2].

       

      In response to discussion in Prague draft-ietf-ca= lext-jscalendar was split in [1] and [2]. Their content is meant to be clos= e to the same.  As the original document was ready for working group l= ast call, the WGLC runs for the two documents [1] and [2].  Please review carefully the two documents and provide y= our feedback/support on the mailing list.

       

      The WGLC ends on May 22 2019.

       

      Yours,

      Bron and Daniel

       

      [1] https://datatracker.ietf.org/doc/draft-ietf-cale= xt-jscalendar/

      [2] https://datatracker.ietf.org/doc/draft-ietf-cale= xt-jscalendar-icalendar/

      --_000_DM6PR15MB35316FC8613A0A9D1DF5C142E3330DM6PR15MB3531namp_-- From nobody Sat May 11 10:53:49 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26D012004A for ; Sat, 11 May 2019 10:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 PDdZTTCfwjLD for ; Sat, 11 May 2019 10:53:45 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 31C18120026 for ; Sat, 11 May 2019 10:53:45 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id 9so7059694itf.4 for ; Sat, 11 May 2019 10:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version; bh=9gSnoqfNZwGGesfUAq/kNoaIZvluzISIEC79jsOxoIo=; b=FTlCu6Auj58ermJhqx9im0wzGavurcKi4a9SSdSgUFUcIM5gYUpBm3wgFmS04jRCLk dgS74vqAkVPW9Jy58EdG7kSSQkVHfq0/oqazpYIe2FO3eMYvKAR9MZVtaL+IbtrIHB76 LZNnSA0ylRbUcUBKlQvqPbCIGdCCOeTEXEMJDMeSd4S9G6bNvOQJaxWNWRDOuqurli39 5BVsoS8knIEDLfotaTyIdQbyzwq+eCDLdQpAAjPHDsxAf6MekAio7wV/ZJU8LrVX+/Ng xvNIElcSx0FzSUF3wKiPeL/fTqSWv+jrP0LlkxcQtKIK9HtSmON5YN6wPLjtG3zi3DjY P9Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version; bh=9gSnoqfNZwGGesfUAq/kNoaIZvluzISIEC79jsOxoIo=; b=niOczVy5zL4Jppb6uQQZ2SMmd/rxI2rfX75PjEWh1zXomK4wB7EtQ9R0FJimL4IhxK jQxRGNGDbUVeaRpejavfaTPx1xez9xrs1KL5oAOcn+YtBAnhpWOmu8jNxbFrwiv9x2mD rFvzIFWirca+dHxKns6nt8KagodJssb1ZnGD4VFiCsrOzaWK/JNdKcH0lnsXir66CrW1 WN+Oy1p7p0m/rLiB8z7fF+2dckSFNmjBfB3USmJ6hRFxVnPiJKlmF86iFGQzYSOYKgCq frhc/NOPrkmBr0sCgrBqj6pH4Wfo9jPek2WMWLetRMzwCk/5lkZfXXp+NDWy/8GQJ4iM kYnA== X-Gm-Message-State: APjAAAXJJKdHOWAwyG5kQ3sv2SI5JrZhZ+0ebGEQVilGpQiKYtaCIr7L KX/WTQDPD24QjOO59GTHtHiC/w3zDJDj X-Google-Smtp-Source: APXvYqwTs35wJQ5V+lAILeSL8r311vi9MjDG2U4Npv40WbINmoJEGjDWAmMAQBLbntcWkKbD3Kb+Dg== X-Received: by 2002:a02:c64a:: with SMTP id k10mr12273226jan.30.1557597224047; Sat, 11 May 2019 10:53:44 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id u11sm875214iot.44.2019.05.11.10.53.42 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 11 May 2019 10:53:43 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org Organization: http://SoftwareAndServices.NET Message-ID: Date: Sat, 11 May 2019 11:53:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090300040103020803050802" Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar - thoughts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 17:53:48 -0000 This is a cryptographically signed message in MIME format. --------------ms090300040103020803050802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On another thread (in ietf@ietf.org) someone declared=20 draft-ietf-calext-jscalendar as a replacement for iCalendar [RFC5545].=20 Not sure if that was the official position or an individuals view. I=20 initially read the draft and updates with the idea that it was another=20 representation of iCalendar. First, a ton of hard work was done on this draft. My comments below are=20 my second thoughts after hearing it is a replacement and not a=20 representation of iCalendar. So I re-read this draft with replacement in = mind. These are not necessarily problems, just thoughts and questions. **I understand that many of these topics may have been discussed on=20 the mailing list. However, if not in the spec when released, they will=20 be confusing. ** 1. If it is a replacement for iCalendar, please provide a list of=20 obsoleted properties and and some kind of migration path for the=20 replacement. Some comments in the spec imply obsoleted properties, they=20 are not named at all in this spec. (DTEND for example - which I think=20 should have never made it into iCalendar). Is this by design? If so,=20 what exactly? 2. Ambiguous ways of representing the same event. When it comes to=20 recurring events, they can still be represented with an RRULE=20 (recurrenceRule) OR with RDATE (recurrenceDates), or a combination. I=20 could not find mention of a preferred way. (Something like use=20 recurrenceRule only, except when it is not possible, then add=20 recurrenceDates, and/or recurrenceOverrides ). 2.1 Same with updates to events that have recurrences. EXACTLY what is=20 sent in the update? A complete replacement? Just what changes? These are = also ambiguous in iCalendar/iTIP/iMIP. 3. iTIP/iMIP Is a jCal iTIP/iMIP replacement in the works? If not, those = rescheduling ambiguities still exist. What (exactly) to send back when=20 requesting a change to the schedule. Send the entire object, just the=20 recurrence-id that is being requested with the proposed updates? Or what?= 3.1 Are jCal iTIP/iMIP messages sent in jCal format or iCalendar format? What is the jCal mapping for the iTIP/iMIP objects? How are PUBLISH,=20 REQUEST, REPLY, ADD, ... method represented in jCal? As this spec does=20 not mention them, does a CUA send them out in iCalendar format, even=20 when the original message was in jCal format? Is there a plan? Or are=20 the iTIP methods to be declared obsolete? 4. How does this relate to WebDAV and its objects, methods, or=20 procedures? Only a brief mention is included. 5. Is a iCalendar to jCal migration path specification in the works? 6. Unrelated to ambiguous. Why are alarms/alerts still sent? Does anyone = accept an alarm the organizer sends out? Example, I live 30 minutes=20 away. What good is a 5-minute alarm to me? What do you do if someone=20 sends an updated alarm/alert in an iTIP COUNTER? Is it ignored? Used as=20 the suggested update? 6.1 Will people really be sharing the 'snoozed' property of an=20 alarm/alert with others? 6.2 Alarm/alert "... *acknowledged*: "UTCDate" (optional) When the user has permanently dismissed the alert the client MUST set this to the current time in UTC. Other clients which sync this property can then automatically dismiss or suppress duplicate= alerts (alerts with the same alert id that triggered on or before this date-time). Is there a plan to separate user specific data from shared data? Clearly = this is not to be shared with the organizer or other participants. And=20 is not supposed to be updated on the master object from the organizer.=20 (Thinking WebDAV where everyone can share the same link to the same event= ). Their seems to be two kinds of data, API data (alerts) and public data=20 (what the organizer would send). What implementations send back and=20 forth between participant and organizer is not defined (ambiguous). This is kind of talked about under "4.6.1 localizations", but I=20 understand 'localizations' to mean language specific, not private data. See useDefaultAlerts under localizations. 6.3 Where is valarm? Gone? Alert mentions alarms, yet no definition of=20 alarm. 7. Under "Security Considerations" Should it mention "do not send private data to organizer"? And a list of = what NOT to send: Alarms, Alert updates/snooze/... 8. I am confused by highlighting meaning of *this*, _this_, and "this"=20 As described in 1.3 and the highlighting methods throughout this spec. I have not seen these used in a draft before. 9. The term "master object" is used once and not defined. Is this the=20 organizer object? Or the users copy? 10. The 'JSGroup' object seems to be new to jCalendar and iCalendar. Did = I miss something in past documents? 11. Color (4.2.10). Can't imagine implements would not just totally=20 ignore this property from organizer. 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever be=20 set to false? Can I send it in object set to false at all? When would it = be valid to set it to false? What is the point of ever being able to=20 send one set to false? 13. Should alerts be excluded from a 'PatchObject'? 14. In 4.4.3 privacy: what is a 'sharee'? Is a sharee a participant? Or=20 a non-Participant? How can a completely hidden ("as though it did not=20 exist") calendar be shared? 14.1 Is any calendar event shared when it has more than 1 participant?=20 (ambiguous) Or does shared mean the same object is shared between=20 participants (as in one persistent storage object shared between=20 participants)? Because if the objects have multiple copies (one per=20 calendar user agent), then what does secret mean? Does it mean that=20 calendar user agents MUST NOT make the event viewable by others in their = own calendars? So they would just mark it as unavailable time (ambiguous)= =2E 14.2 Public, so can I limit what I share and still call it public. Can I = for example limit the viewing of other participants, but otherwise make=20 it public? 14.3 "private" and "hidden ... [from]... sharee". From participants? Or=20 just from non-participants? 14.4 Are not ALL calendar objects shared when there is more than one=20 participant? 14.5 The same iTIP problem exists. When a participant updates their=20 attendee status, and the calendar is public, what exactly does (if=20 anything) the organizer send out to other participants? I would prefer=20 nothing at all. 15. 4.4.5 participants "memberOf" Exactly how is this used? It is a new=20 property to calendar - correct? --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms090300040103020803050802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTExMTc1MzQyWjAvBgkqhkiG9w0BCQQx IgQgbiMb28zjX6Kn0I8YsdAjNbbbaxlPPYkHsqJF789nCE0wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAghHk8RZ34dR1oBdoR5nJ5S1ZKB49O8keyIIIibin1Gn5FyAJL+GkWzX+ om3dc49q88Rp6eUaorDwtDrbozuqOqoFB0f1MzOvCJepk6zf+9ZAjoUarrLUUpcYGTHziIrN CO6w4nSILSLGAA2+2q+2SpRcTtQThyVzLLFWxX7NCwjopmUPLzsWVXbtXaRvlXUX8GAMoaqN fQzDGzgSg1fPeOZHHGpYzedx4ZZdo++Fw1iwhoaMfASKBXPAoQuzqRqR6m4DTM2r/wM712sy gROzGU7/PCZM4gVOgLzPLqNxn9f53KSxs7+80nQb8lAVu5ebZWlT3gkr3ToKpZ2i6R2ssAAA AAAAAA== --------------ms090300040103020803050802-- From nobody Sat May 11 12:43:52 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45DB12011F; Sat, 11 May 2019 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 kPWuBgs2yJfO; Sat, 11 May 2019 12:43:48 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 A393D12003E; Sat, 11 May 2019 12:43:44 -0700 (PDT) Authentication-Results: mail.aegee.org/x4BJheiR021564; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1557603822; i=dkim+MSA-tls@aegee.org; r=y; bh=XBs9Pj+RLtzgOtQ4QFoCKCHJbakifzLVhrnqBpw0Djk=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=mfODy9m722jwvRoWkoqyLMEwhCKnvj255dSdhV3tPTRMuldf6OQhFtiVx/tsHXSvS 12yy5WcvlpLTyNCY7XviVBFBMMGx2jo8kM3E4I0CUPpeH0HuuzDPiCIcrHe2Ya0/oB woTvj0CTTbeLAEZr/tXL3ydvzMQPy4dsuS9Cz2BuMm+DR16WrE8FlR9lmD44wamcoY ejWXl/cMGIDouqEMnovg2itUaJsaF5c0yihWBifX5gheyU9qYJPTJeFyyIt+hMG8eO dKzeQQpg/y85ilyGhLNEN5tigMjP/y4npNknBqMIQxp5jkt/4eWQYJ9ZlfI1duJtj8 2t7/Uowdc9noYKfGjDd3/5tp4s8q0E93R3q8KR0QqEizIH1fooHe0GGIr2IHcDi5cL wZ8HNrLddIa3GImbQLSgLa+5C+7D5KU5rxiSMYDblXoPg/f1z6g1nphd8TRY6QywP8 lEgcNA0qIfTj+jngq92Ix/qOEhE0amLoGCArrZKbuttqsX53qHIYTEBCrxEKj4tu8D 85eR25n+k2ft0sy0ihbJYbxjoNbSjCb3VX3djXjnX26wewZPkkIM78maMPeGgnSpUh eFUj21J2MzKgg2EftMifv1M9txdYHGITT+NoC4aoieHU5sCd094vyw7gCECQ7AWHCz eFHUq4VItBjhovJGzB5IFlpg= Authentication-Results: mail.aegee.org/x4BJheiR021564; dkim=none Received: from Tylan (p5B081767.dip0.t-ipconnect.de [91.8.23.103]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x4BJheiR021564 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 11 May 2019 19:43:41 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: ietf@ietf.org, IETF-Announce Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Date: Sat, 11 May 2019 19:43:40 +0000 In-Reply-To: <155534444001.10836.4918464706630882842.idtracker@ietfa.amsl.com> References: <155534444001.10836.4918464706630882842.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] Last Call: (Event Publishing Extensions to iCalendar) to Proposed Standard X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 19:43:51 -0000 Hello, the email of Thomas Schäfer from 24.10.2018 to calsify@ietf.org was not tackled. For this particular document too many things need to repeated, in order to get attention. > The following properties are defined in this specification Colon afterwards? Regards Дилян On Mon, 2019-04-15 at 09:07 -0700, The IESG wrote: > The IESG has received a request from the Calendaring Extensions WG (calext) > to consider the following document: - 'Event Publishing Extensions to > iCalendar' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2019-04-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > This specification updates RFC5545 by introducing a number of new > iCalendar properties and components which are of particular use for > event publishers and in social networking. > > This specification also defines a new STRUCTURED-DATA property for > iCalendar RFC5545 to allow for data that is directly pertinent to an > event or task to be included with the calendar data. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 13 07:56:45 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331E1120120 for ; Mon, 13 May 2019 07:56:43 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=UQDw7zEJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O4qhbGz5 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 LammugMmZrsM for ; Mon, 13 May 2019 07:56:40 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB21120094 for ; Mon, 13 May 2019 07:56:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3F17223555 for ; Mon, 13 May 2019 10:56:39 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 13 May 2019 10:56:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=DEiJMfU v+tulkEd95+KRZyYgOjritLV+/6iwqXkVynk=; b=UQDw7zEJRalDZjvc6caYpwx UpRft+Dz45MSbYzv2ae9tXVqlTkI95OInVAAWPztUpGjAkTfP511Uv0GLCPgEVw9 wX80wHhiEtT1FQDOwIA+c4cEhr/QG56Oahn+oZ2ao3ROx7K1FgtisodaFY8lIOrb 5U8/5w+fo5Tq4EKIFyZtS3IjFi+WWXYy1w3MpRJVLPMDGuq/AZcnOWI6paxzIRnc 1g1F1Ev8210mHm02FVnumh4wlzBON53iKT5dPDfSB41p4RumUyjrTPlIWlTuezTO krNCkkdWgqNpLgIvdCcDXLWeEYCXWJ9qmwedZV9X/tPnK9WCmB6ChNplOo3G21Q= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DEiJMf Uv+tulkEd95+KRZyYgOjritLV+/6iwqXkVynk=; b=O4qhbGz5SKYvwAHn/ufuBJ aDAKWeMdn5VUrFaagdJeWuv1YJToDiss4zI+yDa4p9g+d5c6qZmZRL0rZ9O7xBT3 tlDZoBFcPU+GNzO1/yCqc0q9wof/kdVIDPLjh7nJIAn/jirXceWlEYm/hRa2RL/7 wfJZ1+EUhA5183DNsCWXycf20wZt4OAPHeGnEs5nOFJnUjt/T/ztzAostR4k7ikQ 4mTNsbiBdsr7N8EVVtTXTX/N/gtq46sTqUuEWuPj6xfpHpElqM8GZOOllGqVU7KH Bs/enfF52pqrXVRnRQQSLC9svOcBna4t0/9hO+/UrWb/Z/6n7llWYL62o6KNEy4A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleeggdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 96406211CD; Mon, 13 May 2019 10:56:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-453-g9eaa09e-fmstable-20190430v2bis Mime-Version: 1.0 Message-Id: <9c2a894f-2ab1-4a05-9ced-885f1801155a@beta.fastmail.com> In-Reply-To: References: Date: Mon, 13 May 2019 10:56:24 -0400 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=4618fc4fc1b94b6b8bf8234aaf81ad6c Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - thoughts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 14:56:43 -0000 --4618fc4fc1b94b6b8bf8234aaf81ad6c Content-Type: text/plain Doug, many thanks for your feedback - much appreciated. Please see my answers below: On Sat, May 11, 2019, at 7:53 PM, Doug Royer wrote: > I initially read the draft and updates with the idea that it was another > representation of iCalendar. > [...] So I re-read this draft with replacement in > mind. These are not necessarily problems, just thoughts and questions. I am not sure what you mean by "replacement" and "representation", so let me clarify my point of view: JSCalendar defines a data model and format for calendaring data, as an alternative to iCalendar. It shares a lot of concepts with iCalendar, but it deliberately isn't 100% compatible. If by "representation" you mean "a different format to express exactly the same thing", then JSCalendar isn't a representation of iCalendar. As to replacement: we think that JSCalendar is the better alternative to iCalendar for a large number of use case (otherwise, why we bother with it). But as it currently stands, it just defines a data format. We haven't started on working out how to use it with iMIP/iTIP, and we are just getting started defining how to use JSCalendar with other protocols (e.g. JMAP). The current RFC document is the ground work required to get started with this. It can be useful in its own as a data format, but as a replacement in iMIP/iTIP it is not ready. > 1. If it is a replacement for iCalendar, please provide a list of > obsoleted properties and and some kind of migration path for the > replacement. Some comments in the spec imply obsoleted properties, they > are not named at all in this spec. (DTEND for example - which I think > should have never made it into iCalendar). Is this by design? If so, > what exactly? We recently uploaded an informational RFC draft which describes how JSCalendar and iCalendar could be mapped, but implementations are free to choose their own conversions: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar-00 > 2. Ambiguous ways of representing the same event. When it comes to > recurring events, they can still be represented with an RRULE > (recurrenceRule) OR with RDATE (recurrenceDates), or a combination. I > could not find mention of a preferred way. (Something like use > recurrenceRule only, except when it is not possible, then add > recurrenceDates, and/or recurrenceOverrides ). We had discussed this, but decided against it. One of the reasons is, that it makes checking the validity of a JSCalendar object more complex, as implementations need to apply recurrence expansion during validity checking. > 2.1 Same with updates to events that have recurrences. EXACTLY what is > sent in the update? [...] > 3. iTIP/iMIP Is a jCal iTIP/iMIP replacement in the works? [...] > 3.1 Are jCal iTIP/iMIP messages sent in jCal format or iCalendar format? > 4. How does this relate to WebDAV and its objects [...] All this is out of scope of the data format. We don't have a proposal, yet (but we'd be happy to hear any!). > 5. Is a iCalendar to jCal migration path specification in the works? I guess you mean JSCalendar, rather than jCal? Please see my reply to your question 1. > 6. Unrelated to ambiguous. Why are alarms/alerts still sent? Does anyone > accept an alarm the organizer sends out? Similar to iMIP, we don't enforce this on the data format level. Personally, I agree that alerts only make sense per user and organizers typically don't know which alerts I require. > 6.3 Where is valarm? Gone? Alert mentions alarms, yet no definition of > alarm. JSCalendar standard alerts are the alternative to VALARM. They define time-based triggers and have a "display" and "email" action, but without describing the content of these triggers. That's due to the observation, that server providers and client devices typically have their own way to render the alert, and especially devices can make better decisions how to alert a user under the current circumstances. > 7. Under "Security Considerations" > Should it mention "do not send private data to organizer"? And a list of > what NOT to send: Alarms, Alert updates/snooze/... Again, that will to be defined, but is out of scope of the current RFC. > 8. I am confused by highlighting meaning of *this*, _this_, and "this" > As described in 1.3 and the highlighting methods throughout this spec. > I have not seen these used in a draft before. The notation should make things simpler to read, not make them more confusing. I'm sorry if it failed on you. Would you have an example of an RFC which achieves this better? I'll also look at recent RFCs for different formats. > 9. The term "master object" is used once and not defined. Is this the > organizer object? Or the users copy? It meant the main event in a recurring event (e.g. in iCalendar the VEVENT without RECURRENCE-ID). I took note to phrase this better. > 10. The 'JSGroup' object seems to be new to jCalendar and iCalendar. Did > I miss something in past documents? JSGroup is a very light wrapper around JSEvent and JSTask. It's similar to a VCALENDAR component that contains VEVENT and VTODO. > 11. Color (4.2.10). Can't imagine implements would not just totally > ignore this property from organizer. Out of scope of the data format, but yes: agreed :) > 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever be > set to false? Can I send it in object set to false at all? When would it > be valid to set it to false? What is the point of ever being able to > send one set to false? This property represents what's EXDATEs in iCalendar. It could be set to false, but it's only really useful to set it to true, or not at all. > 13. Should alerts be excluded from a 'PatchObject'? I guess you mean during an iMIP exchange, right? That would sense, but it's not decided in this RFC. > 14. In 4.4.3 privacy: what is a 'sharee'? Is a sharee a participant? Or > [..] I'm sorry to sound like a broken record, but we don't address this in this RFC. But these are all good questions that we'll need to answer! > 15. 4.4.5 participants "memberOf" Exactly how is this used? It is a new > property to calendar - correct? It's iCalendar alternative is the MEMBER parameter on the ATTENDEE (https://tools.ietf.org/html/rfc5545#section-3.2.11) --4618fc4fc1b94b6b8bf8234aaf81ad6c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
      Doug, many than= ks for your feedback - much appreciated. Please see my answers below:

      On Sat, May 11, 2019, at 7:53 PM, Doug Royer = wrote:
      I initially rea= d the draft and updates with the idea that it was another 
      representation of iCalendar.
      [...] So I re-read this= draft with replacement in 
      mind. These are not neces= sarily problems, just thoughts and questions.

      I am not sure what you mean by "replacement" and "repres= entation", so let me clarify my point of view:

      <= div>JSCalendar defines a data model and format for calendaring data, as = an alternative to iCalendar. It shares a lot of concepts with iCalendar,= but it deliberately isn't 100% compatible. If by "representation" you m= ean "a different format to express exactly the same thing", then JSCalen= dar isn't a representation of iCalendar.

      As= to replacement: we think that JSCalendar is the better alternative to i= Calendar for a large number of use case (otherwise, why we bother with i= t). But as it currently stands, it just defines a data format. We haven'= t started on working out how to use it with iMIP/iTIP, and we are just g= etting started defining how to use JSCalendar with other protocols (e.g.= JMAP). The current RFC document is the ground work required to get star= ted with this. It can be useful in its own as a data format, but as a re= placement in iMIP/iTIP it is not ready.

      1. If it is a replacement for iCalendar= , please provide a list of 
      obsoleted properties and = and some kind of migration path for the 
      replacement.= Some comments in the spec imply obsoleted properties, they 
      are not named at all in this spec. (DTEND for example - which I = think 
      should have never made it into iCalendar). Is = this by design? If so, 
      what exactly?

      We recently uploaded an informational RFC dr= aft which describes how JSCalendar and iCalendar could be mapped, but im= plementations are free to choose their own conversions:

      2. Ambiguous ways of representing the same event. When= it comes to 
      recurring events, they can still be rep= resented with an RRULE 
      (recurrenceRule) OR with RDAT= E (recurrenceDates), or a combination. I 
      could not f= ind mention of a preferred way. (Something like use 
      = recurrenceRule only, except when it is not possible, then add 
      <= /div>
      recurrenceDates, and/or recurrenceOverrides ).

      We had discussed this, but decided against it= . One of the reasons is, that it makes checking the validity of a JSCale= ndar object more complex, as implementations need to apply recurrence ex= pansion during validity checking.

      2.1 Same with updates to events that have rec= urrences. EXACTLY what is 
      sent in the update? [...]<= br>
      3. iTIP/iMIP Is a jCal iTIP/iMIP replacement in the works?= [...]
      3.1 Are jCal iTIP/iMIP messages sent in jCal format= or iCalendar format?
      4. How does this relate to WebDAV an= d its objects [...]

      All this i= s out of scope of the data format. We don't have a proposal, yet (but we= 'd be happy to hear any!).

      5. Is a iCalendar to jCal migration path specificati= on in the works?

      I guess you m= ean JSCalendar, rather than jCal? Please see my reply to your question 1= .

      6. Unrela= ted to ambiguous. Why are alarms/alerts still sent? Does anyone 
      accept an alarm the organizer sends out?

      Similar to iMIP, we don't enforce this on the dat= a format level. Personally, I agree that alerts only make sense per user= and organizers typically don't know which alerts I require.

      6.3 Where is valar= m? Gone? Alert mentions alarms, yet no definition of 
      alarm.

      JSCalendar standard al= erts are the alternative to VALARM. They define time-based triggers and = have a "display" and "email" action, but without describing the content = of these triggers. That's due to the observation, that server providers = and client devices typically have their own way to render the alert, and= especially devices can make better decisions how to alert a user under = the current circumstances.

      7. Under "Security Considerations"
      Sho= uld it mention "do not send private data to organizer"? And a list of&nb= sp;
      what NOT to send: Alarms, Alert updates/snooze/...
      =

      Again, that will to be defined, b= ut is out of scope of the current RFC.

      8. I am confused by highlighting meaning of = *this*, _this_, and "this" 
      As described in 1.3 and t= he highlighting methods throughout this spec.
      I have not s= een these used in a draft before.

      <= div>The notation should make things simpler to read, not make them more = confusing. I'm sorry if it failed on you. Would you have an example of a= n RFC which achieves this better? I'll also look at recent RFCs for diff= erent formats.

      9. The term "master object" is used once and not defined. Is thi= s the 
      organizer object? Or the users copy?
      =

      It meant the main event in a recurring = event (e.g. in iCalendar the VEVENT without RECURRENCE-ID). I took note = to phrase this better.

      10. The 'JSGroup' object seems to be new to jCalendar and iCal= endar. Did 
      I miss something in past documents?

      JSGroup is a very light wrapper ar= ound JSEvent and JSTask. It's similar to a VCALENDAR component that cont= ains VEVENT and VTODO.

      11. Color (4.2.10). Can't imagine implements would not j= ust totally 
      ignore this property from organizer.
      =

      Out of scope of the data format, = but yes: agreed :)

      12. _excluded_ property (4.3.2). I assume (ambiguous) if it ca= n ever be 
      set to false? Can I send it in object set = to false at all? When would it 
      be valid to set it to= false? What is the point of ever being able to 
      send= one set to false?

      This proper= ty represents what's EXDATEs in iCalendar. It could be set to false, but= it's only really useful to set it to true, or not at all.

      13. Should alerts be= excluded from a 'PatchObject'?

      I guess you mean during an iMIP exchange, right? That would sense, but= it's not decided in this RFC.

      14. In 4.4.3 privacy: what is a 'sharee'? Is a sha= ree a participant? Or 
      [..]

      I'm sorry to sound like a broken record, but we don't a= ddress this in this RFC. But these are all good questions that we'll nee= d to answer!

      15. 4.4.5 participants "memberOf" Exactly how is this used? It is = a new 
      property to calendar - correct?

      It's iCalendar alternative is the MEMBER par= ameter on the ATTENDEE (https://tools.ietf.org/html/rfc5545#section-3.2.11)


      --4618fc4fc1b94b6b8bf8234aaf81ad6c-- From nobody Mon May 13 14:13:00 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D61812006A for ; Mon, 13 May 2019 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 xiugnV-Xm4if for ; Mon, 13 May 2019 14:12:58 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 2B1FB120019 for ; Mon, 13 May 2019 14:12:58 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id z4so11295167iol.0 for ; Mon, 13 May 2019 14:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=c5yeoiw50jwllxPQrQTQkwDT1PPzIAG7AL3PLbdC4JI=; b=leLX01ITSMG4YYUssRXacvCFO+b+evvDnI+u9xIqTs3ILpk4oBKPlUxk4AEyx3o88d XHKsM70a5udL7Jw3rflRLb259F2UMXiXs0BMoySj8t+3fx9c0WboMREcF4r10m/qlNQK /J9dl6F+3cXA/RIgsNvfURLC0uppW6FCd9v7Dsb3EFL8EEuk9zB6oG/VKTeWgoi8wysa Cm89vFEbE5mezGNsi7SGOEprZnLrmrKTaWk+NIRkgQKo99Q0KitbiJDKwaiMimHIj/1d 7mhFW9OdcOASf9uJZpDqjQOK/mGgjTuNAyVSWzpxYTLkEeRwSSH3kewhU1cW1itP8eSc um/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=c5yeoiw50jwllxPQrQTQkwDT1PPzIAG7AL3PLbdC4JI=; b=EPozA+Gylv4AqTc/rHu/fONGIhUTjK4avPJ1N6Ga5L7W3GPJ+Ejcb+SbjjA20lUJRM HyB2VICfBkUGHTaIeDqdcVvS+TgR9WnYfD1CsdWuUxJguWPvEs+idWWigoudINrhFWrM HWpbN9t0r6VWRa8519YwcDYavjpHd1labfNLMHqMGELBX0aQ71NtnYQkR9lSZloq6lf3 Y/robBdiyyTZ9R4rm6EQtgcm8Y/7fK9jKdG3UfXcT8uMOIqHUbi2947crztFhoMSs/ot ckZ3gp2WntMz6d3bygQzsl3VrPRQ1yKCCqews+Z4HWnRxUYChUBRf8lgx9lD59Of3W/S Fp/A== X-Gm-Message-State: APjAAAUZaDC75WmB7jn26zq0a5bt/LRPflruSI38bYQQ8BEaTb9VDEGs +ou7oRljzVtT1gohdIVgbIEUNrNR75kf X-Google-Smtp-Source: APXvYqwLWaOPKdaFUbS4mU20HsneIDrHWkFng4Z1poCZciG/44UfWLsD1F+5rLpnKCraXJRYqbWAZw== X-Received: by 2002:a5d:8cc7:: with SMTP id k7mr18594763iot.194.1557781976964; Mon, 13 May 2019 14:12:56 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id z19sm5192178iol.24.2019.05.13.14.12.55 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 14:12:55 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <9c2a894f-2ab1-4a05-9ced-885f1801155a@beta.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <699bca56-ecd3-b142-0a32-3635eed5237c@gmail.com> Date: Mon, 13 May 2019 15:12:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9c2a894f-2ab1-4a05-9ced-885f1801155a@beta.fastmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070300070506060005000603" Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - thoughts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 21:13:00 -0000 This is a cryptographically signed message in MIME format. --------------ms070300070506060005000603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/13/19 8:56 AM, Robert Stepanek [Masked] wrote: > Preview: Doug, many thanks for your feedback - much appreciated. Pleas > On Sat, May 11, 2019, at 7:53 PM, Doug Royer wrote: >> I initially read the draft and updates with the idea that it was anoth= er >> representation of iCalendar. >> [...] So I re-read this draft with replacement in >> mind. These are not necessarily problems, just thoughts and questions.= >=20 > I am not sure what you mean by "replacement" and "representation", so=20 > let me clarify my point of view: >=20 > JSCalendar defines a data model and format for calendaring data, as an = > alternative to iCalendar. It shares a lot of concepts with iCalendar,=20 > but it deliberately isn't 100% compatible. If by "representation" you=20 > mean "a different format to express exactly the same thing", then=20 > JSCalendar isn't a representation of iCalendar. I mean as described in the ietf@ietf.org list email as described in my=20 original post to this list. > As to replacement: ... Thanks for the replies ... new drafts to read ... :-) --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms070300070506060005000603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTEzMjExMjU1WjAvBgkqhkiG9w0BCQQx IgQgQjW3MclYEDb6GKlylY/XPcWADGyQUdGuoDx5yjAhs8swbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAHdFM4w1IDAq0n/N/+4VM5oZT7Pdbe86yzd4Hz6Sn2fR2MX/1AI6126lK pX0qzAieX3Sur66Y6C4M03VBHmQE2aL7ETLpS9nPl4fKx3gMXbEESN16BYQt0FN7K2UcRuSL e9g+AwG/jXy5cBMg4BsU3OkrdAdNBUq6tAYWcHNpo4iCRh5AOx2FwLiq4honm2tqCxVjlo6o 4N2/8A8N8W2lAnEmUXROxTZ2923g1HqZg3GHjUnwy5oRHrdxbljOg6Ghvw2BvVmHqZWIJBgq ViTh2HHEJBr1gWlRoVmxhUdtfakN+0zl0hqIy5aLODmxUv29dzIHBb0P8oCey82ZbY5RvwAA AAAAAA== --------------ms070300070506060005000603-- From nobody Mon May 13 15:09:01 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B043120086 for ; Mon, 13 May 2019 15:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 MkZLKHmis6ZU for ; Mon, 13 May 2019 15:08:58 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 27185120006 for ; Mon, 13 May 2019 15:08:52 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id 9so1613363itf.4 for ; Mon, 13 May 2019 15:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=iY/YI85+PkmrmsXc2dsxxs+ze8Gihjw3hdnk8PaXnOY=; b=X4/AQ4quJrGGd9iLNLQpsm5eHLeK9BzdtsDtZ8zSCt1aUTLS3clBxuZ7xP/APgJP0R pGfRmfLQCX5hQgLTjok5zkrylQ8hJKLL2yYZBzK2OXQnrQ85Djcyt47WgSPf4XVY/i30 +CMJhik0t6XKqlfoJzxQLkIv4xkIZzdhcjyBOpYHgqA0d+VgyZB2YBTmLbFWXg5Tm1w7 XqpSf6HKZQNIhkGw6qFoDhMqI0rOW5TYuAUbp3kcjECVebcpeHQuxFW38mf4uZeh/nJ2 5b9EsTibqB7/7upWMgcXm1fJ26m2d6MKG7c9J6K5QX/TRxEIAy9xst/1yr0gwszA4nMV l3rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=iY/YI85+PkmrmsXc2dsxxs+ze8Gihjw3hdnk8PaXnOY=; b=hYUx+ZB/Q3D1Ep1iBE3U52y9CSyxFqLIldIpB57EvwqOcD7UA1oz9wNV6MUqIkQKqO RKTXG+ZcbNM0+Dh/He8NN2ZgfTdS69Tic1Xz1s+Z/Am9YvAS0iTqMJI2GvSlI3YFSjkw rDPuvN4aoyHv/C0IbIV1MkXUm3rLS56QDXIbHyQDNiL3rxzs53bHLKt+skrvs7Sv4AQC mW8gEXrUdBqsv0R11hDs50LiRHU5xBDJOqORFv59VdzattxsGCuPKaxU3uM4AdtqZZ8A vaFP0YPg+iBwWTPdjX/wtVyjbfsScfuY0SnsgXA52X3RRiN3hrC3lLVj9l/QdHmlSQzX 5/fg== X-Gm-Message-State: APjAAAXNJTpzVfn3HBe2FIBIWV5bd6qm33GnOHz97VHMLdKI5cY0N9s8 v1E8OP26fQm9yhLzGbZSmC3j+o/5W4c1 X-Google-Smtp-Source: APXvYqz47g7tyOICSnayqc+AqsaVclDFkgl95cha/nGJ/nzBji1dbLuR029I3r0To/+6UGncxOwn1g== X-Received: by 2002:a05:660c:10:: with SMTP id q16mr1107186itj.149.1557785331024; Mon, 13 May 2019 15:08:51 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id h191sm475417ith.5.2019.05.13.15.08.49 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 15:08:49 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <9c2a894f-2ab1-4a05-9ced-885f1801155a@beta.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Mon, 13 May 2019 16:08:49 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9c2a894f-2ab1-4a05-9ced-885f1801155a@beta.fastmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060601060707020101010501" Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - thoughts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 22:09:00 -0000 This is a cryptographically signed message in MIME format. --------------ms060601060707020101010501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Why change the names and some formats of existing types? One example why were the dashes added to date? (YYYYMMDD vs YYYY-MM-DD) It seems like a lot of work is being done to make it incompatible and=20 complicate the conversion process. In some cases only the case of the token was changed (UID -> uid). I do not see a technical reason, and it just adds to some confusion. Does it really matter to any code? Users will not see the contents. It just seems that someone did not like the names and wanted to start ove= r. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms060601060707020101010501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTEzMjIwODQ5WjAvBgkqhkiG9w0BCQQx IgQgw/Am8R9PO1CZ22CP/di52rYoQTAyT/cGHdQKhzTiEs4wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAUR2xc9e1+5xQ7wHxJ3kU2Eq/t3Jv9qZAFw5XRYI7oPE0YXrX+2d9wMn+ mA3nUHJFED5mQX9yJFShoAGPjhxdW8rsf+fnMT7qmKClJfvdIuN6aGEJRfduBR4eZUE1cDPb onwoDJfuHrD4P/JxB46FG7X6qEvtbqhyFsAQf+G6wFVbF1zNyBvIo5+8g2KiMg+l90KbR9ix GeeCMLbYh0gYmRT+QSjziT1BNV4Od7FvpP76PlyW+Ymxkrp6bK1b6mOH29nWoAho2rTsMNW9 88fYLQ66/Ee4rPUMeOV2SWagOhEJUAqm37mtSX2kq4ogt8RbKiK8cAPq5vvGAkT0izSwbgAA AAAAAA== --------------ms060601060707020101010501-- From nobody Mon May 13 17:42:18 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602AF120026 for ; Mon, 13 May 2019 17:42: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=CTRwevXE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=z6zl5MZv 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 gFPvAtTkLjhJ for ; Mon, 13 May 2019 17:42:08 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C3612008C for ; Mon, 13 May 2019 17:42:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 06D4723E45 for ; Mon, 13 May 2019 20:42:05 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 13 May 2019 20:42:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=4Nb77RT hhQAylxGB4erwkclvO4x4DjN9/BhlVe5cgCs=; b=CTRwevXEati2PkRO71WjKhZ Bpo0+aHfvK9LQfpx49wo56BARkDKrKXTRuWQsFUVdelDKC010TCYSGSgRYRmtqS+ GTxk3BGo/gN/7CHm9Ay/46iZP3cjmJWwB7p1XgrRaGZ8gIgJCV7RooZgPs0/weyU I6OJhndZ5wLhMRY9Bhs/JYVBluN3u2ymi7MeeUiNLCDnySQV/dDiZ1o3UaURVipA wpngQWz8N3/3K5IuPlC50mmLNJfDRtD3pJjK+aA+JDYA8eP8SS6wwGypQpsSm9om /OASxAvxcrq0m0crJtDS2Cn196qqJsR9EBaGlWmPTEUW4TBlLvjelBkLMW3oLHA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4Nb77R ThhQAylxGB4erwkclvO4x4DjN9/BhlVe5cgCs=; b=z6zl5MZvRuaC3yUjwEBnBX CMSD28BtQ4EjODOzsOc+KDuu+yPsaRoFVVH/cbxGSm024pH+NTca0sWc3dcN1AkD 3Xfe/bdpjjUP8RbEaXaqaXSnb8zqLSUZaFs3DVyYA0SQKM9aWmw0dm3BIsXWTUPR tQkUNEm6+FZfuu34ng6dKwNQZQEVPHsExq8dTw5JPr0IWUB65WlnKwC7fLZUn97b 9+tiOHPfQ+H0qicA66OXClVq+gGsIxQvvZU+T/r6bPgooZC69um+qGDbL00VOScd PXu21qM8cfmIXyEZlXG4f531q2R+6pFYLhAq9W4aZaED/P1uErSYl4IkVkXQxROw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleehgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtgho mhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 781FD211D0; Mon, 13 May 2019 20:42:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-529-g8cb173f-fmstable-20190514v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9c2a894f-2ab1-4a05-9ced-885f1801155a@beta.fastmail.com> Date: Tue, 14 May 2019 10:42:04 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=558a224022df41cf9f859be2f6cd0a21 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - thoughts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 00:42:11 -0000 --558a224022df41cf9f859be2f6cd0a21 Content-Type: text/plain On Tue, 14 May 2019, at 08:09, Doug Royer wrote: > Why change the names and some formats of existing types? > One example why were the dashes added to date? (YYYYMMDD vs YYYY-MM-DD) Because rather than define its own date-time format like iCalendar, JSCalendar uses RFC3339 , making it easier to use with a lot of existing libraries. > In some cases only the case of the token was changed (UID -> uid). Clear understandable names and consistent capitalisation inline with common JSON object structure practices were preferred over keeping the exact same names for properties as iCalendar. Regards, Neil. --558a224022df41cf9f859be2f6cd0a21 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
      On Tue, 14 May = 2019, at 08:09, Doug Royer wrote:
      Why change the names and some formats of existing types?
      One example why were the dashes added to date? (YYYYMMDD vs YYY= Y-MM-DD)

      Because rather than d= efine its own date-time format like iCalendar, JSCalendar uses RFC3339, making it easier to u= se with a lot of existing libraries.

      In some cases only the case of the token was c= hanged (UID -> uid).

      Clear = understandable names and consistent capitalisation inline with common JS= ON object structure practices were preferred over keeping the exact same= names for properties as iCalendar.

      Regards= ,
      Neil.
      --558a224022df41cf9f859be2f6cd0a21-- From nobody Mon May 13 17:50:14 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C21200FF for ; Mon, 13 May 2019 17:50:11 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=JRlbgCze; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C8/3lG+x 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 FeawCazr2u4f for ; Mon, 13 May 2019 17:50:10 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADA612008A for ; Mon, 13 May 2019 17:50:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 545642DF for ; Mon, 13 May 2019 20:50:09 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 13 May 2019 20:50:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=z+KQ4ic KtnPF65hHxRIucGW4VzDkod17mrhVGzD+kmY=; b=JRlbgCzew3bavuFqOWwpWAd 8axBMztc1lUxXi0UbymVrvObelK5V9VOxi8LSU/2XaQFm05aXtPS+VDciDW3JfjV ltWtzvgQEBuDLJAk4ju1ycE6Dtkjs7o81lON4NmsS7QCBTkea8D9Z4yI/nSCC7dB m2Et5zrdEprme3hY8Q7toWQVaFka2SjhcP4msazfZXQhtjZp4BmLAF9TNz1IisIA vGXZxY+evlcbW/09oK4nwjn2lBbpMuCPxyv/46/ItQFy3KW+zuzbJfs/Vb+Lf3ly LGn7otKnGhAilwAUKpiEaAilnQlDngT1IfGKqIbfP/EljsU48UKyQpLaph3Ljvg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=z+KQ4i cKtnPF65hHxRIucGW4VzDkod17mrhVGzD+kmY=; b=C8/3lG+xl1ZRuA2K2EB0Lo DqOXN/2huLf7j4WiShOihnwVW3ZPWyGVn+8J4bxyWHlWBbkiUVw+wZJ2oLKRikfG LADeHHyIR84XvPneu67Sqf21iqGXi79Vs9U8nhuP21IeDlw5eQ5TItziTYmVtSdP qjDUW8tMW1chvUClVXyS66naPk3eeSuZy+qxQ20Kg9A/R621+fziWRJXtEvWgsbI aL3B4oZfgeuCVmRLIpiptYcXHx6K44X0nk7GCdSI4kHdGuZhm1thBUTeYWgmArb2 qhUI6nc0DdrBaCbc6erHJ2HNLOY6uZGCrABcNyERpklx7WFemySpbi+TpKcehLcA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleehgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8076B211D1; Mon, 13 May 2019 20:50:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-529-g8cb173f-fmstable-20190514v2 Mime-Version: 1.0 Message-Id: <726bda16-3a71-42a9-9cb4-f20cf42e196b@www.fastmail.com> In-Reply-To: References: <9c2a894f-2ab1-4a05-9ced-885f1801155a@beta.fastmail.com> Date: Tue, 14 May 2019 10:50:08 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=7cf755a0850f44d0a4460e89b249877c Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - thoughts X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 00:50:12 -0000 --7cf755a0850f44d0a4460e89b249877c Content-Type: text/plain Hi Doug, Thanks for engaging here - I'm glad you came across and took a look. This sort of thorough review is really important to creating a good document. I'm going to try to address the reasoning behind one specific bit here -- why differences! Cheers, Bron. On Tue, May 14, 2019, at 08:09, Doug Royer wrote: > Why change the names and some formats of existing types? > One example why were the dashes added to date? (YYYYMMDD vs YYYY-MM-DD) rfc3339 `full-date` and improved readability. YYYY-MM-DD is far superior in terms of lack of ambiguity and even lack of being accidentally interpreted as an integer when roundtripped through type-unsafe languages. > It seems like a lot of work is being done to make it incompatible and > complicate the conversion process. Compatibility is important - a lack of ambiguity and attractiveness to developers is more important if it wants to gain adoption than slavish compatibility with the existing format. > In some cases only the case of the token was changed (UID -> uid). > I do not see a technical reason, and it just adds to some confusion. > Does it really matter to any code? Users will not see the contents. ICALENDAR is case insignificant. JSON is case significant. It's necessary to chose an explicit case for JSON, and we decided on lowercase because that's what's generally expected by JSON-native developers. > It just seems that someone did not like the names and wanted to start over. Usability and familiarity to programmers are important factors, and they were considered when creating a JSON format which is expected to attract usage. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --7cf755a0850f44d0a4460e89b249877c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
      Hi Doug,

      Thanks for engaging here - I'm gla= d you came across and took a look.  This sort of thorough review is= really important to creating a good document.  I'm going to try to= address the reasoning behind one specific bit here -- why differences!<= br>

      Cheers,

      Br= on.

      On Tue, May 14, 2019, at 08:09, Doug Royer wrote:
      =
      Why change the names and = some formats of existing types?
      One example why were the d= ashes added to date? (YYYYMMDD vs YYYY-MM-DD)

      rfc3339 `full-date` and improved readability.  YYYY-MM-DD is far = superior in terms of lack of ambiguity and even lack of being accidental= ly interpreted as an integer when roundtripped through type-unsafe langu= ages.

      It seems like a lot of work is being done to= make it incompatible and 
      complicate the conversion = process.

      Compatibility is important - a lack= of ambiguity and attractiveness to developers is more important if it w= ants to gain adoption than slavish compatibility with the existing forma= t.

      In some cases only the case of the token was ch= anged (UID -> uid).
      I do not see a technical reason, an= d it just adds to some confusion.
      Does it really matter to= any code? Users will not see the contents.

      = ICALENDAR is case insignificant.  JSON is case significant.  I= t's necessary to chose an explicit case for JSON, and we decided on lowe= rcase because that's what's generally expected by JSON-native developers= .

      It just seems that someone did not like the names = and wanted to start over.

      Usability and fami= liarity to programmers are important factors, and they were considered w= hen creating a JSON format which is expected to attract usage.
      =

      Bron.

      --
        Bron Gondwana, CEO, FastMail Pty Ltd
        brong@fastmailteam.com


      <= /html> --7cf755a0850f44d0a4460e89b249877c-- From nobody Mon May 13 18:32:12 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5CA12008C for ; Mon, 13 May 2019 18:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 c9B9N1jwDgj4 for ; Mon, 13 May 2019 18:32:09 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 B41271200FF for ; Mon, 13 May 2019 18:32:09 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id x24so4253514ion.5 for ; Mon, 13 May 2019 18:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version; bh=K8tFV1KL6twUi6N4qtd/AQmmNvXZtICXrbGkWfKEQuY=; b=nNVNV88He62q+pG8bf7bRjfCGuPXbohYBwbHE7DVQoxY1r+apfFbCGAHyp49dGPylf +YRChqQvF55xRWcykUmExIdPHlsMBrLUDJ+coahyRTCPRGS1HlaIPCjRsTUrhDhaO1wK MUMcGUU0hjXbRZVU1sScMkbFzn1plVDE9wiHegnFyEm4G/jlwGSFgbYZOTZLYYAbVIts fpa/gsjuc1A7hNESTWxZTcaXsUP7+LzKspi52sxTJs6PLTLYpT6S2vyNZvx1iNY7dp+8 flUOY28stK8fjkmH7PXX57+7FzKNSOb8nFUOUutRyVWF90mcWD7kTqnW6bhsbsGR7glZ ZglA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version; bh=K8tFV1KL6twUi6N4qtd/AQmmNvXZtICXrbGkWfKEQuY=; b=UQ/S0953p9sNNWsXJUAaBwxMDW3tcwU7EzsNw94AtruJTfnvXLkZ7LTXVhMe9ywqDD jbBUrXEgMRI6jILjoJBueoCGnuTMxb0uMtO8RNfde4bpLm1P5pfA1WdAlwPl0UxqDCbh 7uCuPidVz8mQ30ucFPRIELV/wp6WOwOSX7BlaZ3G7KEH1HepFRvQ1iBSSQ2dfio0fwr/ AzwahwzKx5d9wC3/TZdd1iEVrAzK8fNMcWS8/NDjmLQcpbaylMwZZQI00gWISR5LznBq FmYWfUSa+eamYfRH+55qGRpegRjVO9Xsmfeaa4xVo+TgCcbHm1ukWATDwY8fUvL+bXpp DVgA== X-Gm-Message-State: APjAAAUFS23bOQBaBj4h4NSKC+wPbJ+qhGwZ0mMWWJHX3cOfdeISlKW8 yapUpdpAa0Xtxp1zYAQHp0t5aWROn4Qd X-Google-Smtp-Source: APXvYqw6Bk1D+fVwu7UKWmM1Sj0R3oZ5iGNlIx8CCAksb09gggk9kXc955ZI4eNgwImGA1GBhxXanA== X-Received: by 2002:a6b:a0d:: with SMTP id z13mr1862515ioi.67.1557797528807; Mon, 13 May 2019 18:32:08 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id w194sm662029itb.33.2019.05.13.18.32.07 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 18:32:07 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org Organization: http://SoftwareAndServices.NET Message-ID: Date: Mon, 13 May 2019 19:32:06 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040301090802080404000505" Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar - *this*, _this_ and "this" X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 01:32:11 -0000 This is a cryptographically signed message in MIME format. --------------ms040301090802080404000505 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/13/19 8:56 AM, Robert Stepanek [Masked] wrote: >> 8. I am confused by highlighting meaning of *this*, _this_, and "this= " >> As described in 1.3 and the highlighting methods throughout this spec= =2E >> I have not seen these used in a draft before. > > The notation should make things simpler to read, not make them more > confusing. I'm sorry if it failed on you. Would you have an example of= > an RFC which achieves this better? I'll also look at recent RFCs for > different formats. Actually, I meant it literally. I am confused and do not understand=20 their meaning or difference at all. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms040301090802080404000505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE0MDEzMjA2WjAvBgkqhkiG9w0BCQQx IgQgFBrxrQYLWqFbivZQ27AqE5XQWUmo6Nc4YVEaRGwx8tQwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAOn3AtzAfen7elV5d4XWUmHFcG+M8TwW4/tgt1Erj2yvUF5lMFAW9I5MF pipPvAFQ7SXCQApsVNywNA4ylMcuzM6b91JQDiSjludUQp3DYeD0Q4ASLWK8TXde+bYuR6OM a4+/sZPojwf46dhgEZnF+VicN6knzl6PRdZrAS+jgAgxC2T9v6MhHDnNMrXDRSwcCY4Y7q4x Fgi7hLt2ABiEIdSurfIFQLsNU2AZjqN/Sy89kvLVt8U5LtBDEW6LfpBh24yv1KtwKRbfOo9c 8HIQCJLndnxtSVbjZGHqL8bLzyyFw3eRKi1D+zH+me6r5NKFzR6qGLh5P8acyZKGo0nK3wAA AAAAAA== --------------ms040301090802080404000505-- From nobody Mon May 13 18:36:05 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14849120033 for ; Mon, 13 May 2019 18:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 VP9WfamPKDSL for ; Mon, 13 May 2019 18:36:00 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 AD309120026 for ; Mon, 13 May 2019 18:36:00 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id i63so2199280ita.3 for ; Mon, 13 May 2019 18:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version; bh=+BER4EE4gzFXcWnvMDm/ze7BgZ41NuX4E3S4jWHcBDQ=; b=WYpDTKpTsO+hp/5dPLhjOMpUkBuvjX3TDyURhH0FMd0fT8w1x2MVl5vKkp1Z122zBy quK7OGldRRHCyspZHlM8rgkW592q+h7qAn7YJ2Sq6RD8SdEzwKczBaTudfawEWQqYz+u BvNrXv/B+/hEZOsNMgKbGyhjA4DmV2rMC5Z19gGihrdN5p82Gvd/gRc+kGfangPT/RY9 yDdtOvhJHfGH9SlP8h/pOBeLFj6oDZELr1w828LbnFuSUIfZqQGXrbYDXgapjT2Fz+1M iLzO1hWw7P8wlBKRoPcyigAGzMqxfDstNQJO4iVyHgr/cSbwIgIUK2AawKb7Yj6BhDDk nMVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version; bh=+BER4EE4gzFXcWnvMDm/ze7BgZ41NuX4E3S4jWHcBDQ=; b=pyk+m0gudTg8PS7zNikUrYGaIG5c6kBGNS48ioBsED4ucCNnLMfSBbAsTopdRKEXmP 02s6+sXeihT74S1b2ReECTkhWsHgv/RQl773TY82yLVziOzYePTN1bRjUEoaEGMcElmu JgFzx72Jx0XyS5g+v66RW77kFmEF4RRfrmVt7Q2ZLaDTOlX1/vMuT8DH/Hbn41hDqQn4 nwl4FDbR95m2TcCfVBz8nf8PAORoPb8ZoyFSjOWCWnQpf4X5gWHI2EvJRJ+ko+3Qkt5n 3Fmn+4ocNKdPPLSLIrr/uzz08sdLbPnI3fTnMZmTO07P91ZBBTiw35PAiGkV2UYatS5b yLKQ== X-Gm-Message-State: APjAAAUpuwK1L8352aXrbyqGEyEFmcjwMidvw7knnPu2hGisnnzIm0j8 X1+lgvdUCfDMH7CPkE0/+k4q+rGen/1h X-Google-Smtp-Source: APXvYqx/61zMrkrvr9Qd6MMsxzGDwUKoY4WHhdefzFudDZ1C/0HD95RooBWgUxFPa9xufy7VrJeegw== X-Received: by 2002:a05:660c:404:: with SMTP id c4mr1711114itk.60.1557797759669; Mon, 13 May 2019 18:35:59 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id p132sm864698ita.2.2019.05.13.18.35.58 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 18:35:58 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org Organization: http://SoftwareAndServices.NET Message-ID: <93408f0e-895c-d085-e372-1e27f5aa495b@gmail.com> Date: Mon, 13 May 2019 19:35:58 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090706030805050801090808" Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar - Local store vs exchange X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 01:36:02 -0000 This is a cryptographically signed message in MIME format. --------------ms090706030805050801090808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/13/19 8:56 AM, Robert Stepanek [Masked] wrote: > ... >> 11. Color (4.2.10). Can't imagine implements would not just totally >> ignore this property from organizer. > > Out of scope of the data format, but yes: agreed :) So, there are two categories of representation. Those that will be for=20 local storage - such as color. And those of interest to scheduling? It would be nice for that fact to be documented. Plus any additional=20 that would be useless to send over scheduling exchanges. (along with the = alarms?) --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms090706030805050801090808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE0MDEzNTU4WjAvBgkqhkiG9w0BCQQx IgQgK9B+djOvTRPy59HrQc1H/dP8o547WKqczmCdsWVWMgAwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAn+HCfccdUr6m+xHVS27soN/SGihqWU4usEU2SQSOvOtUOXcDkdMdwIb9 8e+r23I4HHbdBasXZw7NqIkeA9CpxrZ72yuuPWyxEO2+xZycWemAH5/sNserglX0u3MqJLIs lTOwVKLYBnbOGaXFgSWThjsUtEwMVQiZ2GMBghK5P4IRUbQvSsUL4mDjEw2xYMBx2ExhyHvs 0VvTFOmQ0yjg0W+U+xRDukKvdYyLCC0nCI+T68rEy6UW7W5zeuXOv69z2Fm6wde/2tlyFFYv Z7QOft4dsRtvYmhyAmbKtMjStRGN2qg9d0Ngkwkw1rMmP3JVwKIUrpEcW5a9pb3Lz8VwiwAA AAAAAA== --------------ms090706030805050801090808-- From nobody Mon May 13 18:40:40 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657931200B8 for ; Mon, 13 May 2019 18:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 CMAkZVmYWOxL for ; Mon, 13 May 2019 18:40:37 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 46D07120033 for ; Mon, 13 May 2019 18:40:37 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id 9so2205217itf.4 for ; Mon, 13 May 2019 18:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version; bh=Me2QgVTOPm4+OhwpUZgHZb06rsUO3LEDnURbQV8cOv4=; b=XRU6gJLi12fRZqT3D6DR5tcZCkyOa+7qifgXMx3J02h6ToQfV26M9SKNHU8v9envS2 xz1o+FwZApbEdEoQZYu2SFffoxbDO0h17zkJcNMnfmDQJsn7XOVO0S2ATdP3QfIiy+mi mQu22l3vndWD30Jj2KHZi8cOh09TlDCdlljNXZX0f+wDoUdS/Hu8+N392dpQf7IjKit8 DgNmAUJ5Au4svr+uDdAnFoHF8skF0LGrae2mAde5DuWT3ljuGE/TRwXbvnR7wkiHHrF6 VaQF9lr8V0s/K2KAOdYlAJEoT0yzF6NruznDx5tcCZ/a9ssvLvvJoy70kdT+IQ+0HzSW DZ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version; bh=Me2QgVTOPm4+OhwpUZgHZb06rsUO3LEDnURbQV8cOv4=; b=kOd7GiEBx3ehTgUAE1m8aFqt8s46KPD0bNTdyQOAjU2e+GnJJH7OfRI0qUODgagz+v NPEetxJL8vFGqem5DBH2+16QWw7choUZ/Z3bHbTVzL4aGpJmal8ZPrV3QW/ZdgX8KQ11 kpO+XbMZFtSCi4nMh0lSHfGGzSjDSrE7Uv3WqgOaSK5OHiNnK9yOUdN+lg+QoHr5J+RO F2KxEPBhQVXBZblTXO59+j0hUn3wkVwsq0GFQj7cvSa0HVR5r/dQHcKFEHA2BIUnASWZ 2DDXOfadixsQnc40E/c0r+mffv0UXVgN0UDZgPQAQ2R8/3ABMS6KTCPUEq2lrF5vJs3A jS4g== X-Gm-Message-State: APjAAAUSxch6c+uVxVebeX43ZkfsiVydQPLobBUla9xPhcec07TdvcMK tJcYYFytxcbtq3Orxb7ZKn19xgG9SAB/ X-Google-Smtp-Source: APXvYqx+MBSyd/VETmLMNYCHS1Hkmojcco7K22y7mP2DRJartzLbj8Gon0fxAc1yALx22zZi9O9IIQ== X-Received: by 2002:a24:8245:: with SMTP id t66mr1411586itd.121.1557798036322; Mon, 13 May 2019 18:40:36 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id t67sm587636ita.35.2019.05.13.18.40.35 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 18:40:35 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org Organization: http://SoftwareAndServices.NET Message-ID: <3b53a2df-d6bd-7c77-a39a-fb7d151d89c5@gmail.com> Date: Mon, 13 May 2019 19:40:34 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080009000905030702000705" Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar - excluded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 01:40:38 -0000 This is a cryptographically signed message in MIME format. --------------ms080009000905030702000705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable >> 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever >> be set to false? Can I send it in object set to false at all? When >> would it be valid to set it to false? What is the point of ever being= >> able to send one set to false? > > This property represents what's EXDATEs in iCalendar. It could be set > to false, but it's only really useful to set it to true, or not at > all. Just trying to reduce dead code issues in implementations (ambiguous=20 handling and expectations). If the spec specifically said that it should = only be supplied when TRUE, then no code will ever be written to do=20 otherwise. No need to code "... else when set to false ..." because that code would = NEVER execute =3D=3D dead code. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms080009000905030702000705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE0MDE0MDM0WjAvBgkqhkiG9w0BCQQx IgQgJzCB52WL7HIoPfBwllmo5dafrTdttCMqxs/B4gxNhQgwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAhXUEPafZKGqWj9LxZloPy17/2EXxqdZh5/QGbL/Z/qxecZKmyk3j24/F e0mLgWNMcuosXKFwKCiOzl0fnSIKwhBv1Q1jmXODg0FwVXyXBIgFpR2UzV0mA+EtYTNlaoYK OApVwhLGjZDSmy/6dd5PIMQ9SVSRQC/QJYtT+3/g5jGtOpu6CLA2esXIki4RhAN7pUZj+JbM SsxPgZuhp6f9rEWU2wcvjgNjbhd5eeueTuihfi2ANkTOCpZF26UIuLkivi+ekn/gwcyoYZ8a KKHokuLJnNo5M8+yU/ws2ForAFOjsf6qNZcBw+riyBHqwBaTMc2JufwkQSxkbrlZ0GHzfQAA AAAAAA== --------------ms080009000905030702000705-- From nobody Mon May 13 18:47:01 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B5B120033 for ; Mon, 13 May 2019 18:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fp9Fihdpe2qK for ; Mon, 13 May 2019 18:46:58 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 D5382120026 for ; Mon, 13 May 2019 18:46:57 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id q65so2370983itg.2 for ; Mon, 13 May 2019 18:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version; bh=xGOgaM6JDiA8g9biC8pJrXQLG29DJazSMAIc1FqfSBk=; b=U29RKXTc2nf8ML7yj6+ouvgVZwrHXm3zvzBk+CVut4HievnqJqLYGIEWKsB7rT/CBa 6rsu8PD/kEu2IlbiMGlsyt7t7pp2vPh8uIgRopANK5yc3x+3+GoWA1+edeG0YKo6UOEp uDIhq2LmEQD823/1EP4nadIzS9U/5iFFvr9Rr45JnZQ+8d/kdfmZyupBeQVM+prjt09Z ttxDMD1MJxnV07Pr8ADTH0OxHx9K3PK4POkaIRRpGzSl5Dp4xojhGYA4ph6PvVlQdSKM mWevfpZHVSpayveNccuNCR9nIzEt0D1JcLtuQxkTD84veLkCUscYzdbQPtqz21daQIGe Jw3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version; bh=xGOgaM6JDiA8g9biC8pJrXQLG29DJazSMAIc1FqfSBk=; b=b9CVUkaej16p/bsj2k/pvK9dgrF85lk6nWilXSyrdQKBAOFxVqOeBAEdYhtcOQRMjE g8Lw6c9vqYVQRWNabxGX1yxyVpglg0pP3O/wMlRLUecJ5W5HDp1L6whGvURiPM0oEpLQ tqM1S9i3Hmc0SFoOM8dOIW1Rkl9bJ4vw961gfptFa0+bVDF3a9MzkUAYbt7b0Azkev0y 5IzzUIM9pC8esNktcwnld4yeTJMgluLxsk/LTZpbhFZHPzyck4zTHl5BC4xwl9ICk0zU L4RVghf8UJ4iV7zjDMQTgQSlwQ3SZM0kTCBr2Wim+A/LbtFSLwr5w6E8ZTbwWU4Vgl49 eJSA== X-Gm-Message-State: APjAAAU3otZo4WLVzxM0y57pM1CfD4va5ITMkxgVy5KQhwuNUeCLSbxe UJgyWdhQ4lQO9ESC0EplJ1JO89jVvWLU X-Google-Smtp-Source: APXvYqxhM1NbZtEEN220KR7AsZ6RvgaywtruGSq5XEmxS2vezywdV954WWafg+WSEyvJf1Z+2CKpEA== X-Received: by 2002:a02:1142:: with SMTP id 63mr20568071jaf.19.1557798416768; Mon, 13 May 2019 18:46:56 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id c65sm724204itd.11.2019.05.13.18.46.55 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 18:46:56 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org Organization: http://SoftwareAndServices.NET Message-ID: Date: Mon, 13 May 2019 19:46:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010806080605060109010703" Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar - sharee on private? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 01:47:00 -0000 This is a cryptographically signed message in MIME format. --------------ms010806080605060109010703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable >> 14. In 4.4.3 privacy: what is a 'sharee'? Is a sharee a participant? = >> Or [..] > > I'm sorry to sound like a broken record, but we don't address this in > this RFC. But these are all good questions that we'll need to answer! Well, you did address it :-) As it is in the spec. I just do not know=20 which it means (organizer, or when a participant shares his personal=20 calendar, or only when the calendar is shared by organizer to=20 participants?, ....) As I read the section 4.4.3 privacy, it is confusing. I read it to say=20 "when the calendar is private [meaning not shared], .... ... the object=20 is accessed by a sharee" - I am lost? Or maybe a better question is how can it be shared and private? --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms010806080605060109010703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE0MDE0NjU1WjAvBgkqhkiG9w0BCQQx IgQg1vFbpPdueSQD7YCaSqmChgXifzd9fpZgTT4y/zeUemEwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEArMPkpVCnMzILB6sSKRmFiLMNJoNnmaNThpU167Ir+qdvWR9rsL+FaZE4 TcXk3W0Yf9u3k+fdkig7EJaW6wNUCr5AGqlr9rEr4u7QCUuyooyocWEoH6lHBy/PHXNc4fs6 vt1jzZ8V/nnxXq1h7CVzWhMZFc9kvkT6rmdP3LMO+8IpFcQfEUhDbFU8YcHv5D/aYfamEPul uLbF0lcuSk5hMoJjZ3TVrmCQz53OVwpEb0BYxvKrdQqR3aojOINsf9G0YADQB20ORqDwwIva 3JSYDcNs2ARliCCXbX9YBUyGh3Dws1kbmCu2LQf2R5zXW6b/UIDZ/8ou9WJD32ZREfPHQgAA AAAAAA== --------------ms010806080605060109010703-- From nobody Tue May 14 00:55:39 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4C412021F for ; Tue, 14 May 2019 00:55:38 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=mXKMkkCz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zMxng1f1 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 Ra-TG0wwxAKt for ; Tue, 14 May 2019 00:55:36 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0008B1201F8 for ; Tue, 14 May 2019 00:55:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0C3A4557 for ; Tue, 14 May 2019 03:55:34 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 14 May 2019 03:55:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=ORvtVYZ CQQddPXi0FQYAKwn8azatf1KI4RuHaQx7v3M=; b=mXKMkkCz5rKkUO1CBGUfdP1 3e4Hb6jL1JtLXl0/bj4NzFSfAUjxkB+PGRuQNO47JP4t4YoyzuRh3HUPFcOoF0gP h8namc0Cbseam4tb3WBAGRxaBYpbT+46LnE0XhFRlcO0euPb9noYqwTqEoqZtQeE OJPRNITDpeEmBFk7SnZZ2jJHPoRWYJ0+VQH54nx0cvGaq+eDMl+8iS9/Q8pTXxTL 5JkdYq1fWyDBpIKYCG4QJC35hfP3HqdOZ82ML6YPtc3XptKQYuUjk6RH9AK25eQ0 6v0/W+dRNQc9ZZYkmc5hvTB+osTb1dsEZiYxl0wE3iEtfAkA7Q2OvAd76BTWRwA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ORvtVY ZCQQddPXi0FQYAKwn8azatf1KI4RuHaQx7v3M=; b=zMxng1f1iTNREcjwV+IVbv eGn1IbTagRWmCze7rgegFbij68OC4b3HySdoT0afGjop9dkmA0brHE9KQtaNrdwf ooYRi0/q29zJmZOi7J0io3j2rMQcuit2YuXrsoN8SF9VSSjdGwtkDYo+Cw4OPNi8 +ONX9BZUgZX8AOUNdy3e/ghDZgUUnHWAkiG8ZfHth1gZvAe3pKtMN8b+ONvEpOQ5 AMErhDiXCNSI3fg0w1xcM36ycNveYL3ok/Suc8kZAPmlwLxtyz+FPdzNOr1gnWKD g3bWLlnFPczXyDXJCGr+aez5+iObPv+AXZotSbJ0rOzUhMM69GuTDHPCGHQQJjEQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleehgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1389920577; Tue, 14 May 2019 03:55:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-532-g5582127-fmstable-20190514v6 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 14 May 2019 09:55:33 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=75bce049cd194ad7b52c69f0ad571504 Archived-At: Subject: [calsify] =?utf-8?b?PT9VVEYtOD9RP1JlOl9fZHJhZnQtaWV0Zi1jYWxleHQt?= =?utf-8?b?anNjYWxlbmRhcl8tXyp0aGlzKiwgXz01RnRoaXM9NUY/PSAgYW5kICJ0aGlz?= =?utf-8?q?=22?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 07:55:38 -0000 --75bce049cd194ad7b52c69f0ad571504 Content-Type: text/plain On Tue, May 14, 2019, at 3:32 AM, Doug Royer wrote: > On 5/13/19 8:56 AM, Robert Stepanek [Masked] wrote: > >> 8. I am confused by highlighting meaning of *this*, _this_, and "this" > >> As described in 1.3 and the highlighting methods throughout this spec. > >> I have not seen these used in a draft before. > > > > The notation should make things simpler to read, not make them more > > confusing. I'm sorry if it failed on you. Would you have an example of > > an RFC which achieves this better? I'll also look at recent RFCs for > > different formats. > > Actually, I meant it literally. I am confused and do not understand > their meaning or difference at all. Copying the relevant parts of section 1.3: In this document, property and object definitions are formatted like *this* and are referred to in other sections like _this_. Verbatim text is formatted like "this". You refer to this section, so now I'm confused what's confusing :) That being said, using two different notations, one to *define* and another to *refer to* a property, looks awkward to me as well, now that I look at it. If there are no objections, I will change the spec to use a single notation for property names. I still plan to use notation to notate verbatim text (its style literally is called "verb" in the RFC markup language). Does this make things more clear to you? --75bce049cd194ad7b52c69f0ad571504 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
      On Tue, May 14,= 2019, at 3:32 AM, Doug Royer wrote:
      On 5/13/19 8:56 AM, Robert Stepanek [Masked] wrote:
      >> 8. I am confused by highlighting meaning of *this*, _t= his_, and "this"
      >> As described in 1.3 and the high= lighting methods throughout this spec.
      >> I have not= seen these used in a draft before.
      >
      >= ; The notation should make things simpler to read, not make them more
      > confusing. I'm sorry if it failed on you. Would you hav= e an example of
      > an RFC which achieves this better? I'= ll also look at recent RFCs for
      > different formats.

      Actually, I meant it literally. I am confused= and do not understand 
      their meaning or difference a= t all.

      Copying the relevant pa= rts of section 1.3:

      In th=
      is document, property and object definitions
      are formatted like *this* and are referred to in other sections like
      _this_. Verbatim text is formatted like "this".

      =
      You refer to this section, so now I'm confused what's confusing :) = That being said, using two different notations, one to *define* and anot= her to *refer to* a property, looks awkward to me as well, now that I lo= ok at it. If there are no objections, I will change the spec to use a si= ngle notation for property names. I still plan to use notation to notate= verbatim text (its style literally is called "verb" in the RFC markup l= anguage).

      Does this make things more clear = to you?
      --75bce049cd194ad7b52c69f0ad571504-- From nobody Tue May 14 06:30:36 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F781200EB for ; Tue, 14 May 2019 06:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 6R6lbCBVIDfx for ; Tue, 14 May 2019 06:30:33 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 DC62F120019 for ; Tue, 14 May 2019 06:30:32 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id e184so4672443ite.1 for ; Tue, 14 May 2019 06:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=ZVzviw8ZjcketbnbW3V6NZeYI6n4U3BC9W/1RdPhZog=; b=Cc46SRDa6tTx2gZh+YvOMzJC+kNh0sB0OZBtcNMr7Yuj1XVEoJklKZuUJNCKM7pxWi SlMm+il9IywYo4bHtrfCZsk+tu9hR5uXjBHxWL9mJzxWuNcUvVEEinJFScHqHME4bENG BodTMKGge+TzWdIn1Dr0ho4S/Gz3RcQS7Gka2Eyxkuf3bHaTgSq/aWb0l8WP7JfsVWrp R80OgSpt/8Tmjv8q+QA2cx/eQ3CErdQpOzu2nfsH2JF92HuKDYY8/V2QGlqjHcbsJCa7 Jy2BRBwXyF+Osu9kfYMa6ozUryeJnwDhygsRMcJ9XsfuNJrrf4l4gqiKmEC57f4vDIb3 GHFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=ZVzviw8ZjcketbnbW3V6NZeYI6n4U3BC9W/1RdPhZog=; b=rd6ftBDoAbpSVfGO4tfNKpPUqZSXm18qnb/V7kYButCuPSvfvmnVJfk2Mjz8T0slN6 6SS5llyWSoQQS8TWcnsLuoaoQnMsUVvho4vC+ENySrRTM4W+AtMoG8QSnOaWVI7KRvOI yUTuD2RPX/g1TucRgBzXr352rfJtMcdZ+us886RB3Nih/k0bi/h+zsRLZujgWdIePYi3 HcdUT2a3ONEbMNgNtEs33DidS2nTdTadlHEDK11eW+BG7deGnoa67l0HwL1ZpmhxOwpk Mtp7MVjrYH/GUQFTQb3ywNQpDScN+DfPk4F2R5VMmNBI5PQTyIcvGuKCaVA5B6YCjzKb GXDQ== X-Gm-Message-State: APjAAAUojck+dDADjRUOUEkV65mSA/u9/8ZrCtO9GYyFKtaXu7tkOzMe 9qW6L6vBsGRyMj0BOR7UJiXoZEolBEAg X-Google-Smtp-Source: APXvYqy5GVBZmCbuG/pA76ihDEo8WhFAYecpQlh0ltK2Q8Cuq5ExJbigZaglq5QA186oPgIV9uAJnQ== X-Received: by 2002:a24:3342:: with SMTP id k63mr3278780itk.130.1557840631711; Tue, 14 May 2019 06:30:31 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.googlemail.com with ESMTPSA id m189sm98246itm.21.2019.05.14.06.30.29 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 06:30:30 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: Organization: http://SoftwareAndServices.NET Message-ID: <55712d74-a292-e68b-17f4-1cd239c070c0@gmail.com> Date: Tue, 14 May 2019 07:30:29 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050400090409040005000002" Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - *this*, _this_ and "this" X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 13:30:34 -0000 This is a cryptographically signed message in MIME format. --------------ms050400090409040005000002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/14/19 1:55 AM, Robert Stepanek [Masked] wrote: > Preview: On Tue, May 14, 2019, at 3:32 AM, Doug Royer wrote: > On 5/13 >=20 > Your Blur Masked Email c52sjc4j7tsm@opayq.com received this from=20 > calsify-bounces@ietf.org. > Blur forwards Masked Emails to you here ? just reply like normal and=20 > Blur keeps your email private. > IF THIS IS SPAM, CLICK HERE TO BLOCK.=20 > >=20 > Masked Emails stop spam, defy tracking, and keep data private. INVITE=20 > FRIENDS TO TRY BLUR PREMIUM AT 50% OFF . >=20 > On Tue, May 14, 2019, at 3:32 AM, Doug Royer wrote: >> On 5/13/19 8:56 AM, Robert Stepanek [Masked] wrote: >> >> 8. I am confused by highlighting meaning of *this*, _this_, and "th= is" >> >> As described in 1.3 and the highlighting methods throughout this sp= ec. >> >> I have not seen these used in a draft before. >> > >> > The notation should make things simpler to read, not make them more >> > confusing. I'm sorry if it failed on you. Would you have an example = of >> > an RFC which achieves this better? I'll also look at recent RFCs for= >> > different formats. >> >> Actually, I meant it literally. I am confused and do not understand >> their meaning or difference at all. >=20 > Copying the relevant parts of section 1.3: >=20 > In this document, property and object definitions > are formatted like *this* and are referred to in other sections like > _this_. Verbatim text is formatted like "this". *Because* _it_ "IS" confusing. No clue what it m_e_a_n_s. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms050400090409040005000002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNTE0MTMzMDI5WjAvBgkqhkiG9w0BCQQx IgQgrxoWoTicrO+xocJXzQV2w4mnoh/iYBQMR2pgc71Le/AwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAB0VA8Qr8UEsoUAbRWS28z1NIT1TxI9OK0aJk74ozEYjRdlhZ/hiulA+/ k5gsYUSDcar5RVXfoAHqV/MwD6gceAu+/yqdkCfM8io/7ji1j9xHB3cdgpdKesBRdHS+/Jpw QUmFmqyu5Fy4yvb5+GeWMNhAs33X8Jo9EvhAHWXWg8Cv/m30xYV46ZSq0zSWk7uaQd1j/E3s dTESyn1rNPmEHZXfHFVcBV5Ki7J/xNnWFALwy+6D2CigzktIXA47tAU135XqzwDJfa8mTqaE /9e8CHUYgTdiXU6ckR1IUMKtzX0MNLnsJ8B8WCcYWvVr/Hyv/XTf/Q/E+TZM/2EFAh1kwQAA AAAAAA== --------------ms050400090409040005000002-- From nobody Tue May 14 13:24:38 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BA412012D for ; Tue, 14 May 2019 13:24:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 sARu_ZKizHiK for ; Tue, 14 May 2019 13:24:31 -0700 (PDT) Received: from mailrelay4-1.pub.mailoutpod1-cph3.one.com (mailrelay4-1.pub.mailoutpod1-cph3.one.com [46.30.210.185]) (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 65A88120021 for ; Tue, 14 May 2019 13:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=ZdEP3f8pzg3huaoFZS71xbnT7h+P1LPNKaKTz792+cI=; b=PdTF1Q/y2bYbb49nzkDARV6y042LtBW3LBzjWkHdR0ES1NspVTVCVJHEDBbFA0ioLXA1FyIfgmF8K 6Ew8wemng4SoRbnu5t77l+wDr0ZYIN3kunaz4sPTN/2gvdW8RZi1fFTncGR4HzgD/b7j86zaYVEZzK IpTiwRY3c6vzBqAk= X-HalOne-Cookie: ad1ebba074927de49c631ea8133e59aa3b7bc825 X-HalOne-ID: 4531e591-7686-11e9-abc4-d0431ea8bb10 Received: from smtp.dmfs.org (unknown [62.224.73.93]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 4531e591-7686-11e9-abc4-d0431ea8bb10; Tue, 14 May 2019 20:24:27 +0000 (UTC) Received: from boss.localdomain (p2E50ED49.dip0.t-ipconnect.de [46.80.237.73]) by smtp.dmfs.org (Postfix) with ESMTPSA id D392C4B4 for ; Tue, 14 May 2019 22:24:26 +0200 (CEST) To: calsify@ietf.org References: <3b53a2df-d6bd-7c77-a39a-fb7d151d89c5@gmail.com> From: Marten Gajda Message-ID: Date: Tue, 14 May 2019 22:24:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3b53a2df-d6bd-7c77-a39a-fb7d151d89c5@gmail.com> Content-Type: multipart/alternative; boundary="------------78B7AFC9BBE3DB63EB56CE70" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - excluded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 20:24:36 -0000 This is a multi-part message in MIME format. --------------78B7AFC9BBE3DB63EB56CE70 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 14.05.19 um 03:40 schrieb Doug Royer: > >> 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever > >> be set to false? Can I send it in object set to false at all? When > >> would it be valid to set it to false? What is the point of ever being > >> able to send one set to false? > > > > This property represents what's EXDATEs in iCalendar. It could be set > > to false, but it's only really useful to set it to true, or not at > > all. > > Just trying to reduce dead code issues in implementations (ambiguous > handling and expectations). If the spec specifically said that it > should only be supplied when TRUE, then no code will ever be written > to do otherwise. > > No need to code "... else when set to false ..." because that code > would NEVER execute == dead code. Every implementation should be able to handle `false`. It's the default if the property is absent and there may be implementations which prefer being explicit rather than relying on defaults. We see this in iCalendar a lot when implementations specify VALUE=DATE-TIME even though it's the default for those properties. I don't see much of an issue here, especially since the `false` path is the same as the "absent" path. Marten > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------78B7AFC9BBE3DB63EB56CE70 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


      Am 14.05.19 um 03:40 schrieb Doug Royer:
      >> 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever
      >> be set to false? Can I send it in object set to false at all? When
      >> would it be valid to set it to false? What is the point of ever being
      >> able to send one set to false?
      >
      > This property represents what's EXDATEs in iCalendar. It could be set
      > to false, but it's only really useful to set it to true, or not at
      > all.

      Just trying to reduce dead code issues in implementations (ambiguous handling and expectations). If the spec specifically said that it should only be supplied when TRUE, then no code will ever be written to do otherwise.

      No need to code "... else when set to false ..." because that code would NEVER execute == dead code.

      Every implementation should be able to handle `false`. It's the default if the property is absent and there may be implementations which prefer being explicit rather than relying on defaults. We see this in iCalendar a lot when implementations specify VALUE=DATE-TIME even though it's the default for those properties.

      I don't see much of an issue here, especially since the `false` path is the same as the "absent" path.

      Marten




      _______________________________________________
      calsify mailing list
      calsify@ietf.org
      https://www.ietf.org/mailman/listinfo/calsify
      
      -- 
      Marten Gajda
      CEO
      
      dmfs GmbH
      Schandauer Straße 34
      01309 Dresden
      GERMANY
      
      phone: +49 177 4427167
      email: marten@dmfs.org
      
      Managing Director: Marten Gajda
      Registered address: Dresden
      Registered No.: AG Dresden HRB 34881
      VAT Reg. No.: DE303248743
      --------------78B7AFC9BBE3DB63EB56CE70-- From nobody Tue May 14 21:30:59 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A98120026; Tue, 14 May 2019 21:30:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: brong@fastmailteam.com, barryleiba@computer.org, calsify@ietf.org, calext-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155789465712.30234.4744999620162231469.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2019 21:30:57 -0700 Archived-At: Subject: [calsify] calext - New Interim Meeting Request X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 04:30:57 -0000 A new interim meeting request has just been submitted by Bron Gondwana. This request requires approval by the Area Director of the Applications and Real-Time Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2019-calext-01 --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana City: Bedford Country: GB Session 1: Date: 2019-06-04 Start Time: 16:00 Europe/London Duration: 01:30 Remote Participation Information: Video/Voice: https://zoom.us/j/4574164360 - Jabber: calext@jabber.ietf.org Agenda Note: --------------------------------------------------------- From nobody Wed May 15 08:56:35 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF30D12032B; Wed, 15 May 2019 08:56:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155793578366.17525.2694124339327683477@ietfa.amsl.com> Date: Wed, 15 May 2019 08:56:23 -0700 Archived-At: Subject: [calsify] Calendaring Extensions (calext) WG Interim Meeting: 2019-06-04 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 15:56:29 -0000 The Calendaring Extensions (calext) Working Group will hold an interim meeting on 2019-06-04 from 16:00 to 17:30 Europe/London. Meeting Location: Bedford, GB Agenda: This will be a combined event with the CalConnect conference. In-person attendance is possible at the Bedford Centre Hotel, 2 St. Mary's lane, Bedford, United Kingdom. Signs to the meeting room will be posted at the hotel. There is also an open codefest in the same location on the 3rd. AGENDA: === Discuss in-progress drafts: 30 min * jscalendar * scheduling controls Discuss proposed next drafts to address: 30 min * vpoll * subscription upgrade * scheduling for jscalendar Future possible work: 15 min * ischedule redux * calendar sharing informational drafts * valarm extensions * caldav sync / proxy Other business: * discussion of work process and review process for ongoing standards work coming from CalConnect * tzdist relationship Information about remote participation: Video/Voice: https://zoom.us/j/4574164360 - Jabber: calext@jabber.ietf.org From nobody Wed May 15 19:08:37 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F081200F4 for ; Wed, 15 May 2019 19:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 12dhLtZR_dWC for ; Wed, 15 May 2019 19:08:33 -0700 (PDT) Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) (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 18FCF1201A0 for ; Wed, 15 May 2019 19:08:33 -0700 (PDT) Received: by mail-qt1-f194.google.com with SMTP id y42so2145328qtk.6 for ; Wed, 15 May 2019 19:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=JGiwSpDN+XMqk4UICBiWPPNkHKPpsvDyIr6USrarATM=; b=sPacHQiK87Nw0J/Fwjo7MR5XsF6cFndTcHW2LEB/hT0WuY2qXIpriYUV4AXlKoem4Y b/Rjb/yNZXsbws4x28P/y75VV6AbSuvrC4JMIjo3aG7SkDrCP2AxUJ6bakI1wGSBeweZ T5q6da8poMlgdaKw7Sje8za6RnxzyypeaCeZKQRRotBnRPVObK3/90OGEnWrcoQ4FexY v34Sm7aHKblEkt5baexcF1CyMr9HlG6+/o4vskxymGO9fbSCA34CiJzZSSlr/LCYuAnV aZxASte5C5l2Qkt7OJ3dSm9yZjnYi3DVVBALLtZ3eK+eGzoiwdUiFbyPwYCSCPKGbC9I iASA== X-Gm-Message-State: APjAAAWWKwI29O0IHOKZx6TyRosxl/cCvuvQAceHWlee7Bc+gb8R87pG AEmnSenTbWFmzUaMmCT6ly9AmNsxqozLrr9SYTU= X-Received: by 2002:ac8:3128:: with SMTP id g37mt38691691qtb.65.1557972511950; Wed, 15 May 2019 19:08:31 -0700 (PDT) MIME-Version: 1.0 References: <155789465712.30234.4744999620162231469.idtracker@ietfa.amsl.com> In-Reply-To: <155789465712.30234.4744999620162231469.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Wed, 15 May 2019 22:08:20 -0400 Message-ID: Cc: Barry Leiba , IETF-Calsify , calext-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000025a85f0588f7be73" Archived-At: Subject: Re: [calsify] calext - New Interim Meeting Request X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 02:08:35 -0000 --00000000000025a85f0588f7be73 Content-Type: text/plain; charset="UTF-8" Please find below the tentative agenda. The intention of these meetings is to help the documents moving forward. Please be pro-active and raise discussion before the meeting, so the WG can provide valuable feed backs. We would appreciate each co-authors provides to the mailing list the status of the draft presented as well as the remaining issues. Please let us know if you have any question. Yours, Daniel and Bron AGENDA: === Discuss in-progress drafts: 30 min * jscalendar * scheduling controls Discuss proposed next drafts to address: 30 min * vpoll * subscription upgrade * scheduling for jscalendar Future possible work: 15 min * ischedule redux * calendar sharing informational drafts * valarm extensions * caldav sync / proxy Other business: * discussion of work process and review process for ongoing standards work coming from CalConnect * tzdist relationship On Wed, May 15, 2019 at 12:31 AM IETF Meeting Session Request Tool < session-request@ietf.org> wrote: > > A new interim meeting request has just been submitted by Bron Gondwana. > > This request requires approval by the Area Director of the Applications > and Real-Time Area > > The meeting can be approved here: > https://datatracker.ietf.org/meeting/interim/request/interim-2019-calext-01 > > > > --------------------------------------------------------- > Working Group Name: Calendaring Extensions > Area Name: Applications and Real-Time Area > Session Requester: Bron Gondwana > > City: Bedford > Country: GB > > > Session 1: > > Date: 2019-06-04 > Start Time: 16:00 Europe/London > Duration: 01:30 > Remote Participation Information: Video/Voice: > https://zoom.us/j/4574164360 - Jabber: calext@jabber.ietf.org > Agenda Note: > > --------------------------------------------------------- > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --00000000000025a85f0588f7be73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Please find below the tentative agenda. T= he intention of these meetings is to help the documents moving forward. Ple= ase be pro-active and raise discussion before the meeting, so the WG can pr= ovide valuable feed backs. We would appreciate each co-authors provides to = the mailing list the status of the draft presented as well as the remaining= issues.

      Please let us kno= w if you have any question.

      Yours,=C2=A0
      Daniel and Bron=C2=A0 =C2=A0

      = =C2=A0

      AG= ENDA:

      = =3D=3D=3D

      =C2=A0

      Di= scuss in-progress drafts: 30 min

      * = jscalendar

      * = scheduling controls

      =C2=A0

      Di= scuss proposed next drafts to address: 30 min

      * = vpoll

      * = subscription upgrade

      * = scheduling for jscalendar

      =C2=A0

      Fu= ture possible work: 15 min

      * = ischedule redux

      * = calendar sharing informational drafts

      * = valarm extensions

      * = caldav sync / proxy

      =C2=A0

      Ot= her business:

      * = discussion of work process and review process for ongoing standards work coming from CalConnect

      * = tzdist relationship

      =C2=A0

      =C2=A0=C2=A0

      On Wed, May 15, 2019 at 12:31 AM IETF Meeting= Session Request Tool <sessi= on-request@ietf.org> wrote:

      A new interim meeting request has just been submitted by Bron Gondwana.

      This request requires approval by the Area Director of the Applications and= Real-Time Area

      The meeting can be approved here:
      https://datatracker.ietf.= org/meeting/interim/request/interim-2019-calext-01



      ---------------------------------------------------------
      Working Group Name: Calendaring Extensions
      Area Name: Applications and Real-Time Area
      Session Requester: Bron Gondwana

      City: Bedford
      Country: GB


      Session 1:

      Date: 2019-06-04
      Start Time: 16:00 Europe/London
      Duration: 01:30
      Remote Participation Information: Video/Voice: https://zoom.us/j/4574164= 360 - Jabber: calext@jabber.ietf.org
      Agenda Note:

      ---------------------------------------------------------

      _______________________________________________
      calsify mailing list
      calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
      --00000000000025a85f0588f7be73-- From nobody Thu May 16 01:14:35 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3925F120059; Thu, 16 May 2019 01:14:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 01:14:20 -0700 Archived-At: Subject: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 08:14:20 -0000 Barry Leiba has entered the following ballot position for draft-ietf-calext-eventpub-extensions-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work in this document; I think there’s useful stuff here, and I appreciate what it took to put it together. Two things at the DISCUSS level: — Sections 5.2, 7.1, and 8.1 — Please see BCP 178 (RFC 6648), and then remove x-name and x-prop. Thanks. — Section 10 — It’s good to refer to RFC 3986 for URI-related security considerations, and all of them do apply here. Something else that comes to mind that comes along with a set of new URIs is whether they actually point to what they say they do. I don’t see that there’s any way to verify that they do, and I’m very skeptical about the effectiveness of warning an end user about this sort of thing, for many reasons. I can see why allowing URIs is convenient and compelling, but I’m very heavily concerned about tracking and other privacy leaks, malicious and deceptive content, and other such problems, especially considering the prevalence of abusive calendar invitations these days. I’m not sure what the answer is here, but let’s have a discussion about it and see where we can go with it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The document organization points below are on the edge of DISCUSS for me, but in the end I thing the document is readable as it is, so I’ve made them COMMENT level. But PLEASE consider what I’m suggesting, because I think it would really help the flow and understandability. — Section 1 — This strikes me as far too much detail for the Introduction. You give a bit of detail about each component, property, and parameter — details that should simply be left for the definitions that come later. Even listing them isn’t necessary, because there’s a table of contents. Having all that in the Introduction puts it out of context: it’s too early in the document for a reader to get the details, and it comes out as rather disorganized, scattered. I suggest merging the paragraph about the PARTICIPANT component into the second paragraph of Section 2, and then removing everything after that from Section 1 entirely. The information should instead go into an introductory paragraph in each added element’s definition section. — Section 2 — This is a better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259] handles such structures and allows richer definitions. There’s an extraneous comma after “JSON”, and it should be “handle” to match the plural subject. — Section 3 — As with Section 1, you’re going into detail about the properties and component, details that again seem out of place. Again, I suggest moving those details into the sections that define those items, and promoting Section 3.1 to be Section 3 (so Section 3 becomes the “Use Cases”). — Section 5.3 — Its value MUST be an integer greater than or equal to 1 that quantifies the order with 1 being the first in the ordering. You quantify cardinal numbers, not ordinal numbers. I think “specifies” is the word you want here. A given value, or the absence of a value, MUST NOT be interpreted on its own. I don’t understand what this means; can you explain? This parameter MAY be applied to any property that allows multiple instances. What about properties that don’t allow multiple instances? This MAY is unnecessary because you already have the equivalent “OPTIONAL” at the beginning if the definition. I think your intent here is this: NEW This parameter MUST NOT be applied to a property that does not allow multiple instances. END — Section 6 — Purpose: This property provides a reference to information about a component such as a participant possibly as a vcard or optionally a plain text typed value. This sentence needs some punctuation or rephrasing in order to make sense. Can you try? — Section 8.1 — Description: This component provides information about an participant in an event, task or poll. Make it “a participant”. From nobody Thu May 16 20:24:50 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828D9120344 for ; Thu, 16 May 2019 20:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4hCfw09We2au for ; Thu, 16 May 2019 20:24:46 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 BA1F1120088 for ; Thu, 16 May 2019 20:24:46 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id m7so4351049ioa.6 for ; Thu, 16 May 2019 20:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AwERbzLLWzLXl5IgVQTb3lHqklGk6+YlaYybidKWs6Y=; b=HsnN4AeEDyPHHXfbZCL40HvGJYrQWkk2c8xDQbezzrLF+33pnJ/Xkl1q1iWUAun/TM HR55hoGgh8ZrKx7c0mvQw4WUS2sCHJFQgbmfXoNYxSAArfUa+TQaOtoGyb+8L9nKM9BM 5Bdd5/wscE45yYHqkL+8s+zyOuA2ka8G0dqinIV0Y4Aq0xfiD2Sob63NueyyJX+S1tL7 piFd4MDMDYXUZ1DQrVNmcvKtmNxZQZ+5mvpug1g5l4xEp/Bmaf/5yyroEkUa1Z42/ulC meSPuAEyVDQhIuYt7fMOZBeqwimYcUImzHTP7EdRw5uSjn/KjsKe1u05rhzaXTkZtMJq 6ksA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=AwERbzLLWzLXl5IgVQTb3lHqklGk6+YlaYybidKWs6Y=; b=Tq/zlZMAeekm0B5RIEtjGeS3F23UI+fNRo4uAvUnK3GScHTHgBQP6R1jZ7wWAak5fL PN2sJzr5E0kjB2bbmOAnz5R9uulKRil928vYS8LVa5mDvC6RpNBSI/Aght4Li9gB0D6F rOpogiMMmrO8Z2v/fdtsutESzx6oOghgysDqMQh7oQ9lZ0kfesIOOscX2QajMVfCedug KfG8jVUYFREw5RymHNTwVINZvEZsbwUK43wjPGABZL0Egt3ZdwibE2JTOUCN8XQ3KsDf N9HHpNG//OPsxA2/qTMNGgao1XmGEZLAHOM0Es+1TcJG5tMzsNl/W+EI+3gpdn1kFan1 5ikA== X-Gm-Message-State: APjAAAX1mfIMFjYequYSiqP2FxaUXl54v+K3HRaL5vpBRIsPHvNdcFhP gBYaACLXBcpOb5pDnoo5mIqWVu8AgY9T X-Google-Smtp-Source: APXvYqyL0+JfRJG7qChk0Km85yy/tW0QAixdW/6AlaoE8JKI6pAUgjrnUgGrIp9u0e9JxU84/Z7EfQ== X-Received: by 2002:a5d:991a:: with SMTP id x26mr13788556iol.112.1558063485772; Thu, 16 May 2019 20:24:45 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.gmail.com with ESMTPSA id k7sm2379631ioh.36.2019.05.16.20.24.44 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 20:24:44 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <3b53a2df-d6bd-7c77-a39a-fb7d151d89c5@gmail.com> Organization: http://SoftwareAndServices.US Message-ID: Date: Thu, 16 May 2019 21:24:43 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - excluded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 03:24:48 -0000 On 5/14/19 2:24 PM, Marten Gajda wrote: > > Am 14.05.19 um 03:40 schrieb Doug Royer: >> >> 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever >> >> be set to false? Can I send it in object set to false at all? When >> >> would it be valid to set it to false? What is the point of ever being >> >> able to send one set to false? >> > >> > This property represents what's EXDATEs in iCalendar. It could be set >> > to false, but it's only really useful to set it to true, or not at >> > all. >> >> Just trying to reduce dead code issues in implementations (ambiguous >> handling and expectations). If the spec specifically said that it >> should only be supplied when TRUE, then no code will ever be written >> to do otherwise. >> >> No need to code "... else when set to false ..." because that code >> would NEVER execute == dead code. > > Every implementation should be able to handle `false`. It's the default > if the property is absent and there may be implementations which prefer > being explicit rather than relying on defaults. We see this in iCalendar > a lot when implementations specify VALUE=DATE-TIME even though it's the > default for those properties. > > I don't see much of an issue here, especially since the `false` path is > the same as the "absent" path. Every implementation being able to handle false is not the same thing as every implementation handling false differently - because it is NOT documented in the spec - so just guess? Yes a small hole. I would bet that some implementations may default to true, others false, then when the two meet, oops happens because of some other seemingly unrelated issue. -- Doug Royer (http://DougRoyer.US http://SoftwareAndServices.US) From nobody Thu May 16 20:50:43 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E895120350 for ; Thu, 16 May 2019 20:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6nnfiPnqXMYI for ; Thu, 16 May 2019 20:50:34 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 034B512006A for ; Thu, 16 May 2019 20:50:34 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id p18so9894834itm.1 for ; Thu, 16 May 2019 20:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Pdny2/L+QxNT3DSICNYRfy45PZK1svF0CgWRY63Ojng=; b=Qz1DeLjM3ve5WtBZKz/LMz+2vqRFEtMcMauyL9yFtIN/mOOs3sE3NxWcET+riJMAJA i4a+cQEn7muslNxCp+0PF58ariy7fASluzCF8IMzuCE8/8h4nfVNfK7UrjmgAoEZbjdz tWb45FR5kW9gK3P58qZ9Cp7ZMO8K6k/2zV7DyToUEkjxqiWOU4Izu0M9//kMFqEj2w0O TfDDLvm/BJQtP9IB2U4hFwrhGHCmm1SuRk9CqDpBhCzUisxgLbewA+KjqZLCXSY4R0cE zNKUg3tBZXIANhIONAykQcOewi8gJNmOadNwRVwmygh406QVyqckazcRo9M25AN9DX4G CR0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Pdny2/L+QxNT3DSICNYRfy45PZK1svF0CgWRY63Ojng=; b=H2O5/ZS2f6lV4WHOq2iIFvEiQIhw6EDH9ep1+ebl/SPH+i3b8kZn8xtBBo0tQnuZiR 7wJClSnQw3d0IrUwHBABl8rTZNP/G6JWgFELp+8+6E4WpFTh7hpOubu9PsvNJz0eciXy lcg48y17xRRzLHsSfxsXCiaV25edLBYkJFDLhTJBDCXI+2NxYx6bDEU8xHThL2KPEAAU yPgkcyoVLbneiWzj0eqau8//tAbAsxOGtF9l2VamTm8/4jFBg4c9Zj6lIaBOZkWsSMbc +PdeCjjLCqscM/pliOBRDEzyT66U0jnl2GHIiemFXpUwt842yvHbqzEOuaf4NIxUIyEI v4og== X-Gm-Message-State: APjAAAXD8J748EBSXayn3RomnEC0wSA4UXailhGn1fm6ssroBl5/CYY4 5lPQazpIZg5C6hiqjXbFYXMxuyTT+ZZb X-Google-Smtp-Source: APXvYqzm28rqLMQ/ycvOYXlf16eXBNp6CqGk4YFwEcttGmtVvaeHFB9Os57Ak8ZDwsViIY6in9J4Ug== X-Received: by 2002:a24:fa42:: with SMTP id v63mr15248847ith.20.1558065033051; Thu, 16 May 2019 20:50:33 -0700 (PDT) Received: from [192.168.1.7] ([174.27.51.111]) by smtp.gmail.com with ESMTPSA id d133sm2922053ita.5.2019.05.16.20.50.31 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 20:50:32 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <3b53a2df-d6bd-7c77-a39a-fb7d151d89c5@gmail.com> Organization: http://SoftwareAndServices.US Message-ID: <6f6096c9-7950-a40d-44d4-fffb62158af0@gmail.com> Date: Thu, 16 May 2019 21:50:31 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - excluded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 03:50:39 -0000 On 5/14/19 2:24 PM, Marten Gajda wrote: > > Am 14.05.19 um 03:40 schrieb Doug Royer: > > I don't see much of an issue here, especially since the `false` path is > the same as the "absent" path. And I just checked, that is not in the spec. A reader would have to assume that. From the spec: 4.3.3. excluded Type: "Boolean" (optional, default:"false") Defines if this object is an overridden, excluded instance of a recurring JSCalendar object (also see Section 4.3.2). If this property value is "true", this calendar object instance MUST be removed from the occurrence expansion. I could assume that when set to false, it is added as an instance and not intended to indicate an instance removed. -- Doug Royer (http://DougRoyer.US http://SoftwareAndServices.US) From nobody Thu May 16 22:41:21 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499331200C1 for ; Thu, 16 May 2019 22:41:19 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ye5joqA+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eple9SJA 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 wKLpxnZSov_H for ; Thu, 16 May 2019 22:41:17 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49517120041 for ; Thu, 16 May 2019 22:41:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4E306248BF for ; Fri, 17 May 2019 01:41:16 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 17 May 2019 01:41:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=EJLRREF LhYhbM7lkZjDssAZdyNfzmuM67UHicMnJWpg=; b=Ye5joqA+8LIMSzYFmlIAuCQ NCI2eCsOMuFmYt+QsHTLOipCWZkh78a2YxgFNesyI1YfnUSNOxCgANaO4nUSr/Bw +pFsa5acBHf4lPDVImiyEWJAypnDoec1/T8Ie9vuqrF2LKoDG7WMX6Y4FeFC5wxF csWsvdoqzwUqXWnEDfLjkjBydnNV3kWrKRI9VFDWXERmkoSqcThQeJIppL7GHAsE wkSoUz/TYNvrAbR/OTXYOCEtV/+hSqJkXIOwzRFdRAjHrGoF7Xxst3d9lUE1g3AF tOLEDSdH3B+3io5dawN7My2fGewc2TBBGW0sA5OnW1hst5NWJRf081Ww4Ku7Z8A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=EJLRRE FLhYhbM7lkZjDssAZdyNfzmuM67UHicMnJWpg=; b=eple9SJA3PO7+Q8qb9TcPh 22e8MNK5LR03gy2HAaAgG8ASV3HiRklcn1swjas7leZJ3JS/rkeoMw3tM+1BEUG/ jU0giJEB0N3GZhiFiuGosvOz4qz1MHo2pRUxwSzx1DpiZUSyDIpuvkOTtLgfGQjF 12BHS2mGxrnsV0Dcip8XPctMau6sPAox4ksI+Rr177dolIswQwsQuFEzXDkroRsi P9VpjMkLiwi+vPXnTxZUz1MYkCLTR50+EldeuRPh/kLYqzm3akH3LJ5WAqeuSclf HSPPOdsbLSGFuAu3g0WRiDGCjOYJnXBJQkp7EGKXpC9V+PIvfMK7ZqnHkxbADnDA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddtuddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 94727211DA; Fri, 17 May 2019 01:41:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-549-ge400f56-fmstable-20190516v3 Mime-Version: 1.0 Message-Id: <010b07d7-388e-42a4-9de7-3c5d2c4c7714@beta.fastmail.com> In-Reply-To: <6f6096c9-7950-a40d-44d4-fffb62158af0@gmail.com> References: <3b53a2df-d6bd-7c77-a39a-fb7d151d89c5@gmail.com> <6f6096c9-7950-a40d-44d4-fffb62158af0@gmail.com> Date: Fri, 17 May 2019 15:41:15 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=7fe3f1f79c524a9386e78ec63216eaa1 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar - excluded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 05:41:19 -0000 --7fe3f1f79c524a9386e78ec63216eaa1 Content-Type: text/plain On Fri, 17 May 2019, at 13:50, Doug Royer wrote: > On 5/14/19 2:24 PM, Marten Gajda wrote: > > I don't see much of an issue here, especially since the `false` path is > > the same as the "absent" path. > > And I just checked, that is not in the spec. A reader would have to > assume that. From the spec: > > 4.3.3. excluded > > Type: "Boolean" (optional, default:"false") The *default: "false"* bit means that absent is the same as false. This is what the default annotation is for. > Defines if this object is an overridden, excluded instance of a > recurring JSCalendar object (also see Section 4.3.2). If this > property value is "true", this calendar object instance MUST be > removed from the occurrence expansion. > > I could assume that when set to false, it is added as an instance and > not intended to indicate an instance removed. I agree it never hurts to be explicit and say that a value of `false` has no effect. Neil. --7fe3f1f79c524a9386e78ec63216eaa1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
      On Fri, 17= May 2019, at 13:50, Doug Royer wrote:
      On 5/14/19 2:24 PM, Marten Gajda wrote:
      &= gt; I don't see much of an issue here, especially since the `false` path= is 
      > the same as the "absent" path.

      And I just checked, that is not in the spec. A reader w= ould have to 
      assume that. From the spec:

      4.3.3.  excluded

      &nb= sp;   Type: "Boolean" (optional, default:"false")

      The default: "false" bit means that= absent is the same as false. This is what the default annotation is for= .

       = ;   Defines if this object is an overridden, excluded instance= of a
          recurring JSCalendar object (also= see Section 4.3.2).  If this
          prop= erty value is "true", this calendar object instance MUST be
          removed from the occurrence expansion.

      I could assume that when set to false, it is added as a= n instance and 
      not intended to indicate an instance = removed.

      I agree it never hurt= s to be explicit and say that a value of false has no effect.=

      Neil.
      --7fe3f1f79c524a9386e78ec63216eaa1-- From nobody Sat May 18 23:53:00 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C32F31200D5; Sat, 18 May 2019 23:52:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, daniel.migault@ericsson.com, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155824877972.30943.11526489467710509788.idtracker@ietfa.amsl.com> Date: Sat, 18 May 2019 23:52:59 -0700 Archived-At: Subject: [calsify] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-calext-eventpub-extensions-12=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2019 06:53:00 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-calext-eventpub-extensions-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone has put into this document. I liked the section 3.1 'use cases' providing insights on the goal, same for the section about extended examples. I only have one comment and a couple of nits. == COMMENT == -- Section 4 -- If this syntax replaces completely or partly the one of RFC 5545, then it should be clear in the text (and I have seen that other iCal RFC use the same introduction). What about the other RFC that also update RFC 5545? Is their syntax also impacted? == NITS == -- Section 1 -- Please introduce VCARD before using the word, other words in this section are obvious to the reader. -- Section 2 -- Missing a '.' at the end of first paragraph. -- Section 5.4 -- Please use https://example.org rather than https://schema.org or is it a reference, existing URI ? -- Section 13 -- Last sentence ends with a ',' From nobody Mon May 20 09:12:09 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167021201F0 for ; Mon, 20 May 2019 09:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sphericalcowgroup-com.20150623.gappssmtp.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 4hprMoKeGcSb for ; Mon, 20 May 2019 09:11:52 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 26ECB1201A3 for ; Mon, 20 May 2019 09:11:51 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id m32so16994137qtf.0 for ; Mon, 20 May 2019 09:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sphericalcowgroup-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=q//CC6+FPk127N34DieqvAxJNFW+nUsNdMBVGg4Wubg=; b=XNhaPo63BhZuTfUN6FTKaC0uopHXvCzMqBUxJhXuY3VZvKkF03ML+zwNMjnRPFm7Zl uj9Pfz4saek/tIBxC2ocXX6u9A2J0MM4TDbqEm2qIWF1r/LQBkR7SjMx3ME1aBX/x7JV 4K1NRdzrxUE6KNV5jWFe4MHrSk3HfcFbwku5vNZOkaGv+kaw5whPn4qYHSmEIRgIML12 6fMYg0mVkTJiR+ndTn+/ENBuybf5+9dq2Eo4IZwrIiLF5TFC8QgeKF6aSJTb2pm5gfP4 hXbzBvlGIMGWt/yjn0VytA8RaD26lBEFqp69zQbvjR1AezqNGwEwyUrPI+VlztoXLxxJ 1Zig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=q//CC6+FPk127N34DieqvAxJNFW+nUsNdMBVGg4Wubg=; b=PzHsxbp/2I6upTGaRgkwvDfe6Z7FyWuLJvq9ZM5RiaCbQsc1/XpFUHNol+32Bhs9Qa 8ZR+KCKhycM+VafOmhD8Q2+CvpuYGpO5WYxzYboe29RwTwkU1TBGa4dOF3yL5ywLJy4Y HStpTVMDKopumF1uBhCVfeCisdHaK3oI3xzwqO0C581l37OyEwyCfskFbIVqVisyy8/T qa7qcmfx/051GC5edsvC1BjESsV0ieIhtZ+0DqNSb22QgQ5qXcdTT+dKxuWM5r82VXnu 7k26wKCqKsKhnJNjJel0ycGnkmQK4XslgG8E5KqHiziHibJ9k87UPHizpBFwe6u3esVv IZVQ== X-Gm-Message-State: APjAAAXj/y8/MBGkuGKHCd8CgVMuOmHlifbSlgYa1RhyKpGC1ir2ljYR 2Sx/VDp1hMuGq4ToMKvnDL4IHU329ZY= X-Google-Smtp-Source: APXvYqyKXpE9F8h+XNejYlsz8EDi1M8cmhY8AnrMVqUcTQD96zOHVl8tAhpmNiFG5i2pq+jxst0Qwg== X-Received: by 2002:ac8:1624:: with SMTP id p33mr13485431qtj.335.1558368709124; Mon, 20 May 2019 09:11:49 -0700 (PDT) Received: from b-192-168-135-163.dynapool.vpn.nyu.edu (vpnrasb-10wp-pat-01.natpool.nyu.edu. [216.165.95.86]) by smtp.gmail.com with ESMTPSA id r129sm8870906qkb.9.2019.05.20.09.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 09:11:42 -0700 (PDT) To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, calsify@ietf.org References: <155824877972.30943.11526489467710509788.idtracker@ietfa.amsl.com> From: Michael Douglass Message-ID: <9c5c64fe-5aa4-982d-f014-69be6e508295@sphericalcowgroup.com> Date: Mon, 20 May 2019 12:11:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155824877972.30943.11526489467710509788.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-calext-eventpub-extensions-12=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 16:11:55 -0000 Thanks for the comments. I'll try to get an update version uploaded in the next few days. I'm at an ISO meeting in Toronto until Thursday night On 5/19/19 02:52, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-calext-eventpub-extensions-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work everyone has put into this document. I liked the section > 3.1 'use cases' providing insights on the goal, same for the section about > extended examples. > > I only have one comment and a couple of nits. > > == COMMENT == > > -- Section 4 -- > > If this syntax replaces completely or partly the one of RFC 5545, then it > should be clear in the text (and I have seen that other iCal RFC use the same > introduction). What about the other RFC that also update RFC 5545? Is their > syntax also impacted? > > == NITS == > > -- Section 1 -- > > Please introduce VCARD before using the word, other words in this section are > obvious to the reader. > > -- Section 2 -- > > Missing a '.' at the end of first paragraph. > > -- Section 5.4 -- > > Please use https://example.org rather than https://schema.org or is it a > reference, existing URI ? > > -- Section 13 -- > > Last sentence ends with a ',' > > From nobody Mon May 20 13:12:23 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C6C1200CE; Mon, 20 May 2019 13:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okqE8Ai7te4d; Mon, 20 May 2019 13:12:19 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECCD12004E; Mon, 20 May 2019 13:12:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id BE6DF300ADA283; Mon, 20 May 2019 16:12:18 -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 3FDTw5_Hp6_N; Mon, 20 May 2019 16:12:18 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 96417300ADA272; Mon, 20 May 2019 16:12:17 -0400 (EDT) Date: Mon, 20 May 2019 16:12:15 -0400 From: Cyrus Daboo To: calsify@ietf.org cc: Michael Douglass , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org Message-ID: 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=5602 Archived-At: Subject: [calsify] Expert review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 20:12:22 -0000 Hi, I am one of the expert reviewers for the IANA iCalendar registries. Below are my comments on draft-ietf-calext-eventpub-extensions-12. This review has focussed solely on the definitions of the new iCalendar elements expected to be published by IANA. I have divided up this review into two sections: the first are issues that I think warrant further discussion; the second are issues that need simple corrections. Part 1 ====== 1. Section 6 (SOURCE): Adding a new value type for an existing property is potentially not backwards compatible as existing implementations may be coded to validate that the SOURCE property is only VALUE=URI. Have any tests been done to see if this change will break any current iCalendar implementations making use of SOURCE? 2. Section 8.1 (PARTICIPANT): should a UID property be required for this component? If not required, should it be optional? Or is there some other "primary key" that should be used to identify the same participant across multiple events ("calendaraddress" is not always present)? 3. Section 8.1 (PARTICIPANT): why isn't GEO property allowed in the component? 4. Section 5.2 (RESTYPE): How does a "remote conference" RESTYPE for a structured resource related to a CONFERENCE property defined by RFC 7986? Shouldn't CONFERENCE be preferred for describing a conference "resource"? 5. Section 5.3 (ORDER): "This parameter MAY be applied to any property that allows multiple instances". Strictly speaking this should result in the modification of lots of existing iCalendar properties to allow inclusion of this parameter. I presume the WG is OK with not requiring this draft to include all the updated property definitions? Or should this be scoped to only the new properties defined in this draft? I am not sure it is meaningful on properties like ATTENDEE Part 2 ====== 1. Section 6: States "The default value type for this property is URI.". However, RFC 7986, which was the original definition of the property states: "Value Type: URI -- no default". i.e., the VALUE parameter MUST always be present - there is no default. This draft must not override that behavior. Please fix. 2. Section 6: I think the Purpose field should include the purpose from RFC 7986. Perhaps this can be re-worded: Purpose: This property provides a reference to information about a component such as a participant possibly as a vcard or optionally a plain text typed value. It can also be used to identify a URI where calendar data can be refreshed from. 3. In Section 6: conformance does not indicate the cardinality of the property. RFC 7986 allows it only once in a VCALENDAR component. What is the cardinality for this new use of it? Also, I prefer the "style" used in RFC 7986 rather than the one using 2119 keywords - but I will leave that up to you. 4. Section 6: in the Description: "In a resource or participant". I understand that a "participant" means the new "PARTICIPANT" component - I think that should be explicitly described. But what is a "resource" - does that mean a "PARTICIPANT" component that represents a resource? Since this property seems to have differenting interpretations depending on the type of component it is used in, I think it would be better to enumerate all the components and describe the behaviors for each (grouping together where appropriate). 5. Section 6: Format definition: the "VALUE" items in the "source = " definition need to be moved to "sourceparam = " to avoid hard-coding the order of parameters. 5545's DTSTART definition shows how that can be done 6. Section 7.1: no cardinality in Conformance. 7. Section 7.1: Format definition: s/This parameter is defined/This property is defined/. 8. Section 7.1: Format definition: The "=" in participanttype should be ":". 9. Section 7.1: Format definition: Please include a definition for the parameters, even if it is only "otherparam". 10. Section 7.2: no cardinality in Conformance. 11. Section 7.2: Format definition: s/This parameter is defined/This property is defined/. 12. Section 7.2: Format definition: The "=" in calendaraddress should be ":". 13. Section 7.2: Format definition: Please include a definition for the parameters, even if it is only "otherparam". 14. Section 7.3: Format definition: as per #6 above, please move VALUE= definitions into the param. 15. Section 7.4: Conformance: "in any iCalendar component". Section 4 shows this component only in a sub-set of others - those should be listed here. Why can't this be used in VJOURNAL or VFREEBUSY? 16. Section 7.4: Format definition: as per #6 above, please move VALUE= definitions into the param. 17: Section 7.5: Conformance: "in any iCalendar component". Section 4 shows this component only in a sub-set of others - those should be listed here. 18. Section 7.5: Format definition: as per #6 above, please move VALUE= definitions into the param. Also, the current definition is wrong - there should not be a "/" after strucresparam. 19. Section 7.6: Conformance: please state explicitly that TEXT is the default value. 20. Section 8.1: Conformance: "in any iCalendar component". Section 4 shows this component only in a sub-set of others - those should be listed here. 21. Section 8.1: no cardinality in Conformance. 22. Section 8.1: Format definition: s/This property is defined/This component is defined/. 23. Section 8.1: rstatus should probably not be present in this component as it is specific to scheduling of VEVENT, VTODO, VJOURNAL, and VFREEBUSY. -- Cyrus Daboo From nobody Fri May 24 10:36:20 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A02120141; Fri, 24 May 2019 10:36:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, daniel.migault@ericsson.com, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155871937902.12230.1159232710328343862.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2019 10:36:19 -0700 Archived-At: Subject: [calsify] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-calext-eventpub-extensions-12=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 17:36:19 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-calext-eventpub-extensions-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of comments/questions: 1) “In addition the SOURCE property defined in [RFC7986] is redefined to allow VALUE=TEXT and broaden its usage.” As you redefine the SOURCE property, this document should probably update RFC7986. 2) “This section defines updates to the tables defined in [RFC5545] and new tables.” I wouldn’t think that the table in RFC5545 need to be “updated”. Isn’t the whole purpose of having a registry that you don’t need to update another document in order to extend the table elements? I would recommend to just define the new and updated elements. 3) “These tables may be updated using the same approaches laid down in Section 8.2.1 of [RFC5545]” I find the use of the word “may” here a bit blurry. I would propose simply “are updated”. 4) Why is this document Proposed Standard? The shepherd write-up sounds like the review and deployment of these extension is currently very limited and therefore experimental might be more appropriate…? It’s looks like the change of the SOURCE property needs standards track, however, maybe it would be better to split this up in a separate document then? 5) Can you maybe further elaborate what the use case for the Order Property Parameter is? 6) “When a LABEL parameter is supplied the language of the label must match that of the content and of the LANGUAGE parameter if present.” Shouldn’t this be a normative MUST? Or actually probably a SHOULD? From nobody Sat May 25 19:44:52 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B324012006B; Sat, 25 May 2019 19:44:50 -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 u4bWEVT62ZRG; Sat, 25 May 2019 19:44:48 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 5DC4D12003E; Sat, 25 May 2019 19:44:48 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id q197so13220055qke.7; Sat, 25 May 2019 19:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=QhFzD2n59jSs34clmi54YVpvmhpssbrexzjrmb1l5HI=; b=YFneFhQx7xGnbhcknWtv2e64cnisEO9t2ECghqqOcJoSLYbMCTzjxaw5PsTzZYDM/L UgNBzbjEuCmXMcBIv2/LsnUxWmnTfDE4D0XiyUPUStjHdBI1ca9+g7LOnzGKBQXnDYMx n/b+wm4z2N5Gw5nzLudUlK9pkmoUirjUVyxr6RaLztSU8Q+GyKuwMHJUpXFeDT0YXgfF MKIQbbDp2LnPVtJCglW58/04CfPVLuh1gitdavt/Ej4uSkH+hLvt8Xl5+VO4pkTQjRJi 77xyXfyJxdxGMKH2bSXLMoB/6LKtlnrfNl3UWe6DNB7qvmiWz2xDVRtVWDP3kpk/BEx6 Qofw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=QhFzD2n59jSs34clmi54YVpvmhpssbrexzjrmb1l5HI=; b=HCJ7dv5MGyka8bGHppS6Ture//5ecjANUMUAL+ff2F+Oc0OSakRORJheZMyW5ED6jz C///FTSDq79eGztIYbpRoQsJvUGflgqlfwhJ2NOQnXPk9xUPJ4/hrHbV6pamww8Ct0sQ 4w0RYiPntZTzZSZyQOm64KoaMSbHxi4NexxE0QPOTQiOpYpLNFTNV3E0MlQ4Db6m074w nJgne7eRy9jgENCVBJpvq/zaa921cyp9EjTeqwkjV960dSYjXhPM+sErGT2Ryk537AlA vvGvbR6e9ECrcOrshfrIeX3wIURyrho6MzUG6OSD23gtenQpvXf3v9sQoBlwFiBaX3yZ MgQA== X-Gm-Message-State: APjAAAWIEPs+OKwE9oiOtgTluCpVpUR1tbhxZLAdqMKZY6Dnz/i5mqvP A5DoP9Lgu6ucBywhfQH2p3iLSRWhirY= X-Google-Smtp-Source: APXvYqwrAjayi3D6Or8xfcp7/EKpRNno0vnZPyWQGRj//eBei2w+mUMiD2JnLeYcNraHFw/IEDmP9A== X-Received: by 2002:ac8:2a46:: with SMTP id l6mr43696314qtl.309.1558838687300; Sat, 25 May 2019 19:44:47 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id c9sm3447157qtc.39.2019.05.25.19.44.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 19:44:46 -0700 (PDT) To: Barry Leiba , The IESG Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org References: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> From: Michael Douglass Message-ID: <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> Date: Sat, 25 May 2019 22:44:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BFF6C8E1D37DC4B691E58425" Content-Language: en-US Archived-At: Subject: Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 02:44:51 -0000 This is a multi-part message in MIME format. --------------BFF6C8E1D37DC4B691E58425 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Barry. On 5/16/19 04:14, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-calext-eventpub-extensions-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for the work in this document; I think there’s useful stuff here, and I > appreciate what it took to put it together. Two things at the DISCUSS level: > > — Sections 5.2, 7.1, and 8.1 — > Please see BCP 178 (RFC 6648), and then remove x-name and x-prop. Thanks. Removed > — Section 10 — > It’s good to refer to RFC 3986 for URI-related security considerations, and all > of them do apply here. > > Something else that comes to mind that comes along with a set of new URIs is > whether they actually point to what they say they do. I don’t see that there’s > any way to verify that they do, and I’m very skeptical about the effectiveness > of warning an end user about this sort of thing, for many reasons. I can see > why allowing URIs is convenient and compelling, but I’m very heavily concerned > about tracking and other privacy leaks, malicious and deceptive content, and > other such problems, especially considering the prevalence of abusive calendar > invitations these days. > > I’m not sure what the answer is here, but let’s have a discussion about it and > see where we can go with it. Maybe a brief discussion at CalConect/IETF meeting? > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The document organization points below are on the edge of DISCUSS for me, but > in the end I thing the document is readable as it is, so I’ve made them COMMENT > level. But PLEASE consider what I’m suggesting, because I think it would > really help the flow and understandability. > > — Section 1 — > This strikes me as far too much detail for the Introduction. You give a bit of > detail about each component, property, and parameter — details that should > simply be left for the definitions that come later. Even listing them isn’t > necessary, because there’s a table of contents. Having all that in the > Introduction puts it out of context: it’s too early in the document for a > reader to get the details, and it comes out as rather disorganized, scattered. > > I suggest merging the paragraph about the PARTICIPANT component into the second > paragraph of Section 2, and then removing everything after that from Section 1 > entirely. The information should instead go into an introductory paragraph in > each added element’s definition section. Done > — Section 2 — > > This is a > better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259] > handles such structures and allows richer definitions. > > There’s an extraneous comma after “JSON”, and it should be “handle” to match > the plural subject. Yes - done > — Section 3 — > As with Section 1, you’re going into detail about the properties and component, > details that again seem out of place. Again, I suggest moving those details > into the sections that define those items, and promoting Section 3.1 to be > Section 3 (so Section 3 becomes the “Use Cases”). > > — Section 5.3 — > > Its value MUST be an integer greater than or equal to 1 that > quantifies the order with 1 being the first in the ordering. > > You quantify cardinal numbers, not ordinal numbers. I think “specifies” is the > word you want here. > > A given value, or the > absence of a value, MUST NOT be interpreted on its own. > > I don’t understand what this means; can you explain? No. Not sure what I was trying to say. I think the preceding sentence is sufficient. > This parameter MAY be applied to any property that allows multiple > instances. > > What about properties that don’t allow multiple instances? This MAY is > unnecessary because you already have the equivalent “OPTIONAL” at the beginning > if the definition. I think your intent here is this: > > NEW > This parameter MUST NOT be applied to a property that does not > allow multiple instances. > END Done > — Section 6 — > > Purpose: This property provides a reference to information about a > component such as a participant possibly as a vcard or optionally > a plain text typed value. > > This sentence needs some punctuation or rephrasing in order to make sense. Can > you try? Is this better? This property provides a reference to information about a component such as a participant. For example, that information may be a vcard or a plain text typed value. > — Section 8.1 — > > Description: This component provides information about an > participant in an event, task or poll. > > Make it “a participant”. Done > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------BFF6C8E1D37DC4B691E58425 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

      Thanks Barry.

      On 5/16/19 04:14, Barry Leiba via Datatracker wrote:
      Barry Leiba has entered the following ballot position for
      draft-ietf-calext-eventpub-extensions-12: Discuss
      
      When responding, please keep the subject line intact and reply to all
      email addresses included in the To and CC lines. (Feel free to cut this
      introductory paragraph, however.)
      
      
      Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
      for more information about IESG DISCUSS and COMMENT positions.
      
      
      The document, along with other ballot positions, can be found here:
      https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
      
      
      
      ----------------------------------------------------------------------
      DISCUSS:
      ----------------------------------------------------------------------
      
      Thanks for the work in this document; I think there’s useful stuff here, and I
      appreciate what it took to put it together.  Two things at the DISCUSS level:
      
      — Sections 5.2, 7.1, and 8.1 —
      Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  Thanks.
      Removed
      — Section 10 —
      It’s good to refer to RFC 3986 for URI-related security considerations, and all
      of them do apply here.
      
      Something else that comes to mind that comes along with a set of new URIs is
      whether they actually point to what they say they do.  I don’t see that there’s
      any way to verify that they do, and I’m very skeptical about the effectiveness
      of warning an end user about this sort of thing, for many reasons.  I can see
      why allowing URIs is convenient and compelling, but I’m very heavily concerned
      about tracking and other privacy leaks, malicious and deceptive content, and
      other such problems, especially considering the prevalence of abusive calendar
      invitations these days.
      
      I’m not sure what the answer is here, but let’s have a discussion about it and
      see where we can go with it.
      Maybe a brief discussion at CalConect/IETF meeting?
      
      ----------------------------------------------------------------------
      COMMENT:
      ----------------------------------------------------------------------
      
      The document organization points below are on the edge of DISCUSS for me, but
      in the end I thing the document is readable as it is, so I’ve made them COMMENT
      level.  But PLEASE consider what I’m suggesting, because I think it would
      really help the flow and understandability.
      
      — Section 1 —
      This strikes me as far too much detail for the Introduction.  You give a bit of
      detail about each component, property, and parameter — details that should
      simply be left for the definitions that come later.  Even listing them isn’t
      necessary, because there’s a table of contents.  Having all that in the
      Introduction puts it out of context: it’s too early in the document for a
      reader to get the details, and it comes out as rather disorganized, scattered.
      
      I suggest merging the paragraph about the PARTICIPANT component into the second
      paragraph of Section 2, and then removing everything after that from Section 1
      entirely.  The information should instead go into an introductory paragraph in
      each added element’s definition section.
      Done
      — Section 2 —
      
         This is a
         better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259]
         handles such structures and allows richer definitions.
      
      There’s an extraneous comma after “JSON”, and it should be “handle” to match
      the plural subject.
      Yes - done
      — Section 3 —
      As with Section 1, you’re going into detail about the properties and component,
      details that again seem out of place.  Again, I suggest moving those details
      into the sections that define those items, and promoting Section 3.1 to be
      Section 3 (so Section 3 becomes the “Use Cases”).
      
      — Section 5.3 —
      
            Its value MUST be an integer greater than or equal to 1 that
            quantifies the order with 1 being the first in the ordering.
      
      You quantify cardinal numbers, not ordinal numbers.  I think “specifies” is the
      word you want here.
      
            A given value, or the
            absence of a value, MUST NOT be interpreted on its own.
      
      I don’t understand what this means; can you explain?
      No. Not sure what I was trying to say. I think the preceding sentence is sufficient.
            This parameter MAY be applied to any property that allows multiple
            instances.
      
      What about properties that don’t allow multiple instances?  This MAY is
      unnecessary because you already have the equivalent “OPTIONAL” at the beginning
      if the definition.  I think your intent here is this:
      
      NEW
            This parameter MUST NOT be applied to a property that does not
            allow multiple instances.
      END
      Done
      — Section 6 —
      
         Purpose:  This property provides a reference to information about a
            component such as a participant possibly as a vcard or optionally
            a plain text typed value.
      
      This sentence needs some punctuation or rephrasing in order to make sense.  Can
      you try?

      Is this better?

      	This property provides a reference to information
      	about a component such as a participant. For example, that 
      	information may be a vcard or a plain text typed value.
      
      — Section 8.1 —
      
         Description:  This component provides information about an
            participant in an event, task or poll.
      
      Make it “a participant”.
      Done
      
      _______________________________________________
      calsify mailing list
      calsify@ietf.org
      https://www.ietf.org/mailman/listinfo/calsify
      
      --------------BFF6C8E1D37DC4B691E58425-- From nobody Sat May 25 19:55:50 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5DB1200C4; Sat, 25 May 2019 19:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 FQP8XZB_TqCK; Sat, 25 May 2019 19:55:47 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 D857312003E; Sat, 25 May 2019 19:55:46 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id w187so2977662qkb.11; Sat, 25 May 2019 19:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4dxpIZpZBMsK+O8VDjM2Q/W8VcD4B2NIbu2c5+eaz24=; b=kZkYC8f1algW+TJf3Fg98S6kRvSlVgcYq2R64K+JzsVju4K0R5xkCtPOgT5C8T/fv8 AYPDUPaO6+WV+/RNg7ZJHkleX1MsXFVFCuB6b/2LXqWgFseQUQ8vkwqC79+GDjgG7jFW RWzWcm+Led9uoEcCHHWx/rxz85ZD75BXAnDJz1SIOIt4eiCv/MW1lEzU8m61V0ojy6+U KlY5SR2p2xQSuaiqwsPUIrJDa1K1P04oiwxZ+4M06yrF4Rrdo5f09RkBvGA4zrQs4cgE 4svHSy5Xjgt94Qidvb6FWQDwrIAYAxeR6NYja6GO17+BbkdQKW57spJNIDZ2fvDlsy34 kvLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=4dxpIZpZBMsK+O8VDjM2Q/W8VcD4B2NIbu2c5+eaz24=; b=Dj1qzZp5tPO9t73/SDqu0SZFSnnlELRLSbCB/Sz7ERUxRlw21zA8XSV6IExCJFvr14 Vz9q1kTG3cvpsdPvKDBBDL1z5wxpCuRuUYaA5NRSRPndJcU6tRwCGALFaYFItq0mvhXT fWBCVaXsssBrGfM7NdHFZU8Q+mhIxRznAS0SlneQ4eOl43iy3QtpM/5hU0wcepUT0qbB msxmw2cwMVKLHpQjlpopKG/ad85CZj8d1fiVzqmw3q4MWXR1XZ/Lt4vZlAj9dK6JGloO Br/3WcXet0vc7ke8Rxe0EbnHcNzs2cXy2TVTvpLjccq51TOF0KXeDNpe2OJy0A/Ca/+4 2Osw== X-Gm-Message-State: APjAAAXr8ijHfcaqZazD08aTWMpQtjJEF9ZTL+4JRMNqkLb+QhrCXYga FwdM6KhTrYDzIbLjci5aZUBy2UpbrMw= X-Google-Smtp-Source: APXvYqyHb3vVQpOSQrKglyqnUXgDuvq4R3KghUB9olKvSCbOlxxkQMIac7+fcYhaTQjRo/3VOu/qqA== X-Received: by 2002:a0c:b929:: with SMTP id u41mr28242618qvf.50.1558839345928; Sat, 25 May 2019 19:55:45 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id k58sm3485377qtc.38.2019.05.25.19.55.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 19:55:45 -0700 (PDT) To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org References: <155824877972.30943.11526489467710509788.idtracker@ietfa.amsl.com> From: Michael Douglass Message-ID: <37f6fcf6-c25e-8bdc-32d7-e7b11d3ab26f@gmail.com> Date: Sat, 25 May 2019 22:55:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155824877972.30943.11526489467710509788.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-calext-eventpub-extensions-12=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 02:55:49 -0000 Thanks Éric On 5/19/19 02:52, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-calext-eventpub-extensions-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work everyone has put into this document. I liked the section > 3.1 'use cases' providing insights on the goal, same for the section about > extended examples. > > I only have one comment and a couple of nits. > > == COMMENT == > > -- Section 4 -- > > If this syntax replaces completely or partly the one of RFC 5545, then it > should be clear in the text (and I have seen that other iCal RFC use the same > introduction). What about the other RFC that also update RFC 5545? Is their > syntax also impacted? > > == NITS == > > -- Section 1 -- > > Please introduce VCARD before using the word, other words in this section are > obvious to the reader. Added a reference > > -- Section 2 -- > > Missing a '.' at the end of first paragraph. Fixed > > -- Section 5.4 -- > > Please use https://example.org rather than https://schema.org or is it a > reference, existing URI ? It's a specific (realistic) example of expected use. Is it OK as is? > > -- Section 13 -- > > Last sentence ends with a ',' Fixed > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Sat May 25 19:57:14 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F70120052; Sat, 25 May 2019 19:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 umchupeWgBZS; Sat, 25 May 2019 19:57:01 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 A537112001E; Sat, 25 May 2019 19:57:01 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id o2so12923579qkb.3; Sat, 25 May 2019 19:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=x88soJ647NL7FuzlWkjJl8RoZ4ZlqdHD3fCCdQqtXic=; b=YRpPs7d5Ng9APUtCj3fpOBCJj1qG7BQDUszmI5a0Y59c0ubam94D95U+14LLkpnE96 ujP9u5RPBvWfm+CpN496ATglXrmxDw9j/0tBlEgv+IJ0lJ6oseamw4tkL+BwUwc4IiXN ICrM+UFWn0tiirUbibmjTg7XBK/HhMsiyER4TYGFPgYZ7/HOB/eDrS+odFCRsSl0+xp1 y5vnbSHABLsc25oE2r39Non36734ggjO4hTOPbUqOTn2sVEKSuIAMwatZym3OfRuHz8v PLo8fHYhgOgTFYduaVHzSkKWI7FUw+1nOzStW0RdSb8q6GCHvEWJ4mRe/L2GfRqNNi3f DgAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=x88soJ647NL7FuzlWkjJl8RoZ4ZlqdHD3fCCdQqtXic=; b=f3yFuMxg0NtDCQyjoYX54r9BJHCDUmVZ9ExrMYna4TtGvgYuO7ynek9JCygjogpW/s xFAZIVBdi76u/iC32Ssjr5GSORLHJYUnxiwwo6Y4aTAzQXCGmyILVaQD2bfMiIyRD4N1 Q/0x8IfJtNee/ekqnbmaZe06p+ahhsEl88aPQdNwlFhW3Bq5yxJbjtpnUeD1LhQub6MM RHJNfboMfAhWqzsyz/A7298vUTFmS9oLzKlsxIVuAkh5EWdCUWs+TyFGIOXX92cOXM5U u8jsUMsySlBCxqozaSMpyzOwqQmyu6VwAuhNEsDFTPcJCnw6Fez29HHRIHoJkCup3TU+ 9YbQ== X-Gm-Message-State: APjAAAUxkTxOCJK9loH/XI2p5Wy6lcab3MAp/rapBm2d3YjPcNxmbkK6 0hDjIE0N1ZtOoBQb2ouptQjCAzSwJpg5qw== X-Google-Smtp-Source: APXvYqzEJ0llKZ6jc+B4QvAHw4EANnyAe6I8n0LIXe5C3oIwLTh+wi7xaL8AlGfEu33hSc/EgrJskw== X-Received: by 2002:ae9:c208:: with SMTP id j8mr12426935qkg.264.1558839420747; Sat, 25 May 2019 19:57:00 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id u2sm2697489qtq.45.2019.05.25.19.56.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 19:57:00 -0700 (PDT) To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , ietf@ietf.org, IETF-Announce Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org References: <155534444001.10836.4918464706630882842.idtracker@ietfa.amsl.com> From: Michael Douglass Message-ID: <0d79c36b-1d18-7351-1016-26dfc2ff2a42@gmail.com> Date: Sat, 25 May 2019 22:56:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Last Call: (Event Publishing Extensions to iCalendar) to Proposed Standard X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 02:57:04 -0000 Thanks Дилян On 5/11/19 15:43, Дилян Палаузов wrote: > Hello, > > the email of Thomas Schäfer from 24.10.2018 to calsify@ietf.org was not tackled. > > For this particular document too many things need to repeated, in order to get attention. Fixed >> The following properties are defined in this specification > Colon afterwards? Restructured for Barry's comments > > Regards > Дилян > > On Mon, 2019-04-15 at 09:07 -0700, The IESG wrote: >> The IESG has received a request from the Calendaring Extensions WG (calext) >> to consider the following document: - 'Event Publishing Extensions to >> iCalendar' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2019-04-29. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This specification updates RFC5545 by introducing a number of new >> iCalendar properties and components which are of particular use for >> event publishers and in social networking. >> >> This specification also defines a new STRUCTURED-DATA property for >> iCalendar RFC5545 to allow for data that is directly pertinent to an >> event or task to be included with the calendar data. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Sat May 25 20:14:50 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6514120099; Sat, 25 May 2019 20:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 V1BJL4PbwYyx; Sat, 25 May 2019 20:14:38 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 42C96120020; Sat, 25 May 2019 20:14:38 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id j1so13241536qkk.12; Sat, 25 May 2019 20:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Ry4CsN27AMk3rw7dcKUsyVjVSxF4PNTPiQyTEW7Hdhc=; b=MFsjOj+8bBrruPZeInNwDDdKfW/flFeG++sVPS73N3elmc07BaEjxBG77Xl9GZohFB JJse5UWjlRPfkZ213aTiPM1FeI5UA/FOKydr0d+eozGIuWKMt4LBlEEkOCzm4M7wJS7s POOfx7vP3Z6QJ5Sve1+z6/X1RxvN7Mz3Zh8ZSRUetZ2WSGBOoDpL5erZ6+NwiwLaZQsR GOL6TC0EwhzrlITedjJhPeCY7aympGqeYPZZNqmKU2SS0My95bOw02T1gvrwp3F+7plZ OTXUlp19P9Qou3qcaJekLGwfUqDLSRRMb7Licza7NJ5y8T6GgEUplcsoHqqi+GdFrWjr PtVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Ry4CsN27AMk3rw7dcKUsyVjVSxF4PNTPiQyTEW7Hdhc=; b=G1VvRdAeZLG+lH+SD41sUMQceU99fr5BXlDu1gVItYotYsTc3x8VZxDq5JmpddXG7X BjWR6TwTtKcQ4Ec1CtArj4fOrFOuQg8usaZdiIv3nvEkFJmeaR2PVKcI+ThDVT5jcAKL cy+gn36xWiDxT3w/Qg21wprAx1S3p7fY3yISpQK5wNdc4YYzFsxLcZ2nHAXakXeNuztl qWqr9qym4x1Y9xCjclzUpFcVwvk/sr8FrO5/yT0YapIlUQ/fHIumzwIIPUWDG0INQeEO 6chizCpn+hS7DV9AMediFbM/n2QZTqj0Io7269VTTLhP7xU7XcSq7LU/FSM6a2ZR6n3Y syIg== X-Gm-Message-State: APjAAAVKEy9rkgoCkVAhOPhXL3LM7/IPqKWsV23IMGo8khkNxanD4mpr LZuJgj+TNnu1pQZfdIFdm7rOKFYKjG8= X-Google-Smtp-Source: APXvYqxkKNlamtqmGfAoj1S9+6m8EASjVJ/IWhKd+ThFt5XlPQ7LGZZCuBiJq0zO4cYtRNvgQNT7Mg== X-Received: by 2002:ac8:4890:: with SMTP id i16mr4338979qtq.72.1558840477081; Sat, 25 May 2019 20:14:37 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id k127sm2804919qkb.96.2019.05.25.20.14.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 20:14:36 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org References: <155871937902.12230.1159232710328343862.idtracker@ietfa.amsl.com> From: Michael Douglass Message-ID: <651c9767-b7b9-c217-6461-f2f132496d3e@gmail.com> Date: Sat, 25 May 2019 23:14:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155871937902.12230.1159232710328343862.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-calext-eventpub-extensions-12=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 03:14:41 -0000 Thanks Mirja On 5/24/19 13:36, Mirja Kühlewind via Datatracker wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-calext-eventpub-extensions-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A couple of comments/questions: > > 1) “In addition the SOURCE property defined in [RFC7986] is redefined to > allow VALUE=TEXT and broaden its usage.” > As you redefine the SOURCE property, this document should probably update > RFC7986. Yes - thanks. > > 2) “This section defines updates to the tables defined in [RFC5545] and new > tables.” I wouldn’t think that the table in RFC5545 need to be “updated”. Isn’t > the whole purpose of having a registry that you don’t need to update another > document in order to extend the table elements? I would recommend to just > define the new and updated elements. Removed that paragraph > > 3) “These tables may be updated using the same > approaches laid down in Section 8.2.1 of [RFC5545]” > I find the use of the word “may” here a bit blurry. I would propose simply “are > updated”. Done > > 4) Why is this document Proposed Standard? The shepherd write-up sounds like > the review and deployment of these extension is currently very limited and > therefore experimental might be more appropriate…? It’s looks like the change > of the SOURCE property needs standards track, however, maybe it would be better > to split this up in a separate document then? Some vendors already use x-properties (if I can use the term) to support a number of the features being standardized here (e.g. locations and rich text). This specification is a attempt to provide a standard for current behaviour > 5) Can you maybe further elaborate what the use case for the Order Property > Parameter is? Added some text giving example use > > 6) “When a LABEL parameter is supplied the language of the label must > match that of the content and of the LANGUAGE parameter if > present.” > Shouldn’t this be a normative MUST? Or actually probably a SHOULD? Yes - done > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Sun May 26 02:31:32 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F92120162; Sun, 26 May 2019 02:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7_aYh9pty36; Sun, 26 May 2019 02:31:29 -0700 (PDT) Received: from mail-it1-f174.google.com (mail-it1-f174.google.com [209.85.166.174]) (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 11FB6120156; Sun, 26 May 2019 02:31:29 -0700 (PDT) Received: by mail-it1-f174.google.com with SMTP id g23so14772882iti.1; Sun, 26 May 2019 02:31:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FGm9M9gvkgJf1r+3NQij/9NuXMaZBzulICPaDyVjn9E=; b=jNOw/9prr/BTwL9DOifik/AcZlogl9GPt5RNkmOx2mX8EVS8VTfr+BEvvLucf0FvMf 85DltH4AyXVprCVfhVCYb4JKAC8/UULgrt1WJL1yjH7DEQLXgFa0KYGPazeApPdrClvh 3no6SFd+ahEaLz9MIyCdbih7af9AWD4Vgj6M87XyDJsCKTlIxwjQGbfDhGLdpEO5VJ8L TA17RHcz390ezRSEwDIjPET5m65OKaJHFYn/pQA6YHAUqX0Z+9fi5ISCBM7QyXbY+sd9 kq/+UEWpJDz2bf7EzKK7cSDqDIf2XratFYJgHrC3DoQAaMuc2nfpYBMSs2jtUb5TO8p8 PxoA== X-Gm-Message-State: APjAAAXaaPk8c8VL55cbgVETqWRZ1kI/e+GS62uj5dR+xJvozX3oSyO9 okvK6ptfqoXIPu6EMvq+SG2BN0eYVjAbr5CYKPA= X-Google-Smtp-Source: APXvYqxuDBizeKC29G4KotJe/3Zvk3Pr9ORAvkfnm2JHt2NUFbDytiprc9kSEuZUUWZ1+IQKmfJdYoqr6VxJ8iaOGAY= X-Received: by 2002:a24:a088:: with SMTP id o130mr23822969ite.86.1558863087977; Sun, 26 May 2019 02:31:27 -0700 (PDT) MIME-Version: 1.0 References: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> In-Reply-To: <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> From: Barry Leiba Date: Sun, 26 May 2019 10:31:16 +0100 Message-ID: To: Michael Douglass Cc: The IESG , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 09:31:30 -0000 Hiya, >> =E2=80=94 Section 10 =E2=80=94 >> It=E2=80=99s good to refer to RFC 3986 for URI-related security consider= ations, and all >> of them do apply here. >> >> Something else that comes to mind that comes along with a set of new URI= s is >> whether they actually point to what they say they do. I don=E2=80=99t s= ee that there=E2=80=99s >> any way to verify that they do, and I=E2=80=99m very skeptical about the= effectiveness >> of warning an end user about this sort of thing, for many reasons. I ca= n see >> why allowing URIs is convenient and compelling, but I=E2=80=99m very hea= vily concerned >> about tracking and other privacy leaks, malicious and deceptive content,= and >> other such problems, especially considering the prevalence of abusive ca= lendar >> invitations these days. >> >> I=E2=80=99m not sure what the answer is here, but let=E2=80=99s have a d= iscussion about it and >> see where we can go with it. > > Maybe a brief discussion at CalConect/IETF meeting? Yes, that sounds like a good idea. We'll hold this until then. >> =E2=80=94 Section 6 =E2=80=94 >> >> Purpose: This property provides a reference to information about a >> component such as a participant possibly as a vcard or optionally >> a plain text typed value. >> >> This sentence needs some punctuation or rephrasing in order to make sens= e. Can >> you try? > > Is this better? > > This property provides a reference to information > about a component such as a participant. For example, that > information may be a vcard or a plain text typed value. Ah, yes, OK: now I get what you're saying. Thanks. Barry From nobody Sun May 26 04:24:21 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADED120113; Sun, 26 May 2019 04:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZQrAUjpyG6dC; Sun, 26 May 2019 04:24:09 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 BD03612015F; Sun, 26 May 2019 04:24:09 -0700 (PDT) Received: from 200116b82c203f004847db3a02583ce0.dip.versatel-1u1.de ([2001:16b8:2c20:3f00:4847:db3a:258:3ce0]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hUrFz-00079x-6k; Sun, 26 May 2019 13:24:03 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: <651c9767-b7b9-c217-6461-f2f132496d3e@gmail.com> Date: Sun, 26 May 2019 13:23:59 +0200 Cc: The IESG , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A4344BA-E2B0-4CE8-BF8F-2493A40A1A53@kuehlewind.net> References: <155871937902.12230.1159232710328343862.idtracker@ietfa.amsl.com> <651c9767-b7b9-c217-6461-f2f132496d3e@gmail.com> To: Michael Douglass X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1558869849;ad7598cb; X-HE-SMSGID: 1hUrFz-00079x-6k Archived-At: Subject: Re: [calsify] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-calext-eventpub-extensions-12=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 11:24:13 -0000 Thanks! If this is already in use, I guess PS is fine. Just the shepherd-write = up sounded differently. > On 26. May 2019, at 05:14, Michael Douglass = wrote: >=20 > Thanks Mirja >=20 > On 5/24/19 13:36, Mirja K=C3=BChlewind via Datatracker wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-calext-eventpub-extensions-12: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> A couple of comments/questions: >>=20 >> 1) =E2=80=9CIn addition the SOURCE property defined in [RFC7986] is = redefined to >> allow VALUE=3DTEXT and broaden its usage.=E2=80=9D >> As you redefine the SOURCE property, this document should probably = update >> RFC7986. > Yes - thanks. >>=20 >> 2) =E2=80=9CThis section defines updates to the tables defined in = [RFC5545] and new >> tables.=E2=80=9D I wouldn=E2=80=99t think that the table in RFC5545 = need to be =E2=80=9Cupdated=E2=80=9D. Isn=E2=80=99t >> the whole purpose of having a registry that you don=E2=80=99t need to = update another >> document in order to extend the table elements? I would recommend to = just >> define the new and updated elements. > Removed that paragraph >>=20 >> 3) =E2=80=9CThese tables may be updated using the same >> approaches laid down in Section 8.2.1 of [RFC5545]=E2=80=9D >> I find the use of the word =E2=80=9Cmay=E2=80=9D here a bit blurry. I = would propose simply =E2=80=9Care >> updated=E2=80=9D. > Done >>=20 >> 4) Why is this document Proposed Standard? The shepherd write-up = sounds like >> the review and deployment of these extension is currently very = limited and >> therefore experimental might be more appropriate=E2=80=A6? It=E2=80=99s= looks like the change >> of the SOURCE property needs standards track, however, maybe it would = be better >> to split this up in a separate document then? >=20 > Some vendors already use x-properties (if I can use the term) to = support a number of the features being standardized here (e.g. locations = and rich text). >=20 > This specification is a attempt to provide a standard for current = behaviour >=20 >> 5) Can you maybe further elaborate what the use case for the Order = Property >> Parameter is? > Added some text giving example use >>=20 >> 6) =E2=80=9CWhen a LABEL parameter is supplied the language of the = label must >> match that of the content and of the LANGUAGE parameter if >> present.=E2=80=9D >> Shouldn=E2=80=99t this be a normative MUST? Or actually probably a = SHOULD? > Yes - done >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >=20 From nobody Sun May 26 20:18:37 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0216A1201E9; Sun, 26 May 2019 20:18:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155892710992.5690.7513259847387084424@ietfa.amsl.com> Date: Sun, 26 May 2019 20:18:30 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-13.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 03:18:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-13.txt Pages : 34 Date : 2019-05-26 Abstract: This specification updates RFC5545 by introducing a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar RFC5545 to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 26 20:19:50 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3732D12021D; Sun, 26 May 2019 20:19:49 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy7SgVDkpiWz; Sun, 26 May 2019 20:19:46 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 49D641200EB; Sun, 26 May 2019 20:19:46 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id i125so13601491qkd.6; Sun, 26 May 2019 20:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=qf6NlagZGWCi8MAB12kdKzG7iOrF4QF2DZBdvUi9sMc=; b=VlfjPuopruDvNKUqZjA/IKZ7YibfjCKb38OB7tECt4Fo+vhEnqyXMhr603xdOQMYKx nm8s4tuqCc6BtydNJZQRLeJCbhMykNz7wzyjaRo2g4dEPwfL1L/ja5OtUF2HPR7xQ5kz 2EQ15uwu4S/evsuRYL5dtAzYklpIga018l/LnbtM/Cn4KNxyc8Z0E35bQ+Tq9to71j8F uIZKdga5ZvLKEYCrfN5cBW6MjdwlducSdpn5NWh+AjNHFA0FuVzznrchjB7hsZJ+GR95 jde1wZLKGjEx5tExUTE0SqnPVCuWoFm4md+2ywgDlAoDlCcV455+tje3c2FvI9ytrcR0 LWmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qf6NlagZGWCi8MAB12kdKzG7iOrF4QF2DZBdvUi9sMc=; b=t32V8UetjrklqDOQ5QMi/PSf7wFAwu/o2E4rHSbj0C5wpD/Yr89t1YqOQmjUbspcPm OdI1pNhqaU/dr8Pk66KzEDLBcL5oG2o7JLng4tBpScNWDseWe8K97tEkfM0AetzB1WD0 +n0W+KRw9EmPKTTGMpF4FVD1BKTSeb3bPjRmskYWWhrFexxHYZwZ3+svTIGPaGhZLZfX 0MK4Vf/SHmWOzPLOCEUOmKRefUP0edx6sSgLmugHbc8Y3XaBC+A0xWFnUHUWr4fDlh2Q c6NOu13j8pN75QxEG6RQR8F+4ftOJmn8XipgVJq0GJWfPrrykYUReCkHBQavM0lSa4fS Gxbw== X-Gm-Message-State: APjAAAWJFJSU1sBZjj4fIk0LjD6LIYfefn54CVj4iBUL504TGhGfpYzc d/DU399KvTiGU3r2mTyM+KXaedM9uFCobA== X-Google-Smtp-Source: APXvYqwXIQwiovmUcMd1bmmjRzlNSG4WHYSHszD3QPMNrKMYcZB62yPYW+0vDfRZTAqUzkDc9DDzeg== X-Received: by 2002:ac8:3f38:: with SMTP id c53mr92137267qtk.214.1558927185275; Sun, 26 May 2019 20:19:45 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id 39sm4708237qtx.71.2019.05.26.20.19.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 May 2019 20:19:44 -0700 (PDT) To: Cyrus Daboo , calsify@ietf.org Cc: Michael Douglass , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org References: From: Michael Douglass Message-ID: <833dc3bd-c4ec-1d32-6715-dda95baf83bb@gmail.com> Date: Sun, 26 May 2019 23:19:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------26F7C3F5B4C8B04CABA3D569" Content-Language: en-US Archived-At: Subject: Re: [calsify] Expert review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 03:19:49 -0000 This is a multi-part message in MIME format. --------------26F7C3F5B4C8B04CABA3D569 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Cyrus. Some follow up questions below for: Part 1 -     #1 still considering that one     #4 Part 2 - #19, 23 Given the number of changes I've submitted an updated draft with these and the previously noted changes. Thanks. On 5/20/19 16:12, Cyrus Daboo wrote: > Hi, > I am one of the expert reviewers for the IANA iCalendar registries. > Below are my comments on draft-ietf-calext-eventpub-extensions-12. > This review has focussed solely on the definitions of the new > iCalendar elements expected to be published by IANA. > > I have divided up this review into two sections: the first are issues > that I think warrant further discussion; the second are issues that > need simple corrections. > > Part 1 > ====== > > 1. Section 6 (SOURCE): Adding a new value type for an existing > property is potentially not backwards compatible as existing > implementations may be coded to validate that the SOURCE property is > only VALUE=URI. Have any tests been done to see if this change will > break any current iCalendar implementations making use of SOURCE? I guess that was the point of not allowing a default? If they don't know how to handle value= then they should ignore it. > > 2. Section 8.1 (PARTICIPANT): should a UID property be required for > this component? If not required, should it be optional? Or is there > some other "primary key" that should be used to identify the same > participant across multiple events ("calendaraddress" is not always > present)? I'm OK with it being required. I hadn't thought of trying to indicate it's the same participant across different events. I guess for example it allows us to know it's the same hockey team for example. Added. > > > 3. Section 8.1 (PARTICIPANT): why isn't GEO property allowed in the > component? Added > > 4. Section 5.2 (RESTYPE): How does a "remote conference" RESTYPE for a > structured resource related to a CONFERENCE property defined by RFC > 7986? Shouldn't CONFERENCE be preferred for describing a conference > "resource"? The intent was not to describe the conference but the resources required for a conference. I guess they could be implied from the conference property > > 5. Section 5.3 (ORDER): "This parameter MAY be applied to any property > that allows multiple instances". Strictly speaking this should result > in the modification of lots of existing iCalendar properties to allow > inclusion of this parameter. I presume the WG is OK with not requiring > this draft to include all the updated property definitions? Or should > this be scoped to only the new properties defined in this draft? I am > not sure it is meaningful on properties like ATTENDEE > > Part 2 > ====== > > 1. Section 6: States "The default value type for this property is > URI.". However, RFC 7986, which was the original definition of the > property states: "Value Type:  URI -- no default". i.e., the VALUE > parameter MUST always be present - there is no default. This draft > must not override that behavior. Please fix. Fixed > > 2. Section 6: I think the Purpose field should include the purpose > from RFC 7986. Perhaps this can be re-worded: > >    Purpose:  This property provides a reference to information about a >          component such as a participant possibly as a vcard or > optionally >          a plain text typed value. It can also be used to identify a URI >          where calendar data can be refreshed from. Added text > > 3. In Section 6: conformance does not indicate the cardinality of the > property. RFC 7986 allows it only once in a VCALENDAR component. What > is the cardinality for this new use of it? Also, I prefer the "style" > used in RFC 7986 rather than the one using 2119 keywords - but I will > leave that up to you. Switched to 7986 wording > > > 4. Section 6: in the Description: "In a resource or participant". I > understand that a "participant" means the new "PARTICIPANT" component > - I think that should be explicitly described. But what is a > "resource" - does that mean a "PARTICIPANT" component that represents > a resource? Since this property seems to have differenting > interpretations depending on the type of component it is used in, I > think it would be better to enumerate all the components and describe > the behaviors for each (grouping together where appropriate). I've made this more restrictive. In a PARTICIPANT component it may provide a reference to a vcard giving directory information. > > 5. Section 6: Format definition: the "VALUE" items in the "source = " > definition need to be moved to "sourceparam = " to avoid hard-coding > the order of parameters. 5545's DTSTART definition shows how that can > be done Pretty sure I copied that out of some other spec... Changed > > 6. Section 7.1: no cardinality in Conformance. Fixed > > 7. Section 7.1: Format definition: s/This parameter is defined/This > property is defined/. Fixed > > 8. Section 7.1: Format definition: The "=" in participanttype should > be ":". Fixed > > 9. Section 7.1: Format definition: Please include a definition for the > parameters, even if it is only "otherparam". Done > > 10. Section 7.2: no cardinality in Conformance. Fixed > > 11. Section 7.2: Format definition: s/This parameter is defined/This > property is defined/. Done > > 12. Section 7.2: Format definition: The "=" in calendaraddress should > be ":". Done > > 13. Section 7.2: Format definition: Please include a definition for > the parameters, even if it is only "otherparam". Done > > 14. Section 7.3: Format definition: as per #6 above, please move > VALUE= definitions into the param. Done > > 15. Section 7.4: Conformance: "in any iCalendar component". Section 4 > shows this component only in a sub-set of others - those should be > listed here. Why can't this be used in VJOURNAL or VFREEBUSY? Omission - added > > 16. Section 7.4: Format definition: as per #6 above, please move > VALUE= definitions into the param. Done > > 17: Section 7.5: Conformance: "in any iCalendar component". Section 4 > shows this component only in a sub-set of others - those should be > listed here. > Done > 18. Section 7.5: Format definition: as per #6 above, please move > VALUE= definitions into the param. Also, the current definition is > wrong - there should not be a "/" after strucresparam. Done > > 19. Section 7.6: Conformance: please state explicitly that TEXT is the > default value. Following the example of the others:     1. Should I remove the default and require VALUE=     2. Move VALUE= and ENCODING= into the params > > 20. Section 8.1: Conformance: "in any iCalendar component". Section 4 > shows this component only in a sub-set of others - those should be > listed here. Fixed > > 21. Section 8.1: no cardinality in Conformance. Fixed > > 22. Section 8.1: Format definition: s/This property is defined/This > component is defined/. Fixed > > 23. Section 8.1: rstatus should probably not be present in this > component as it is specific to scheduling of VEVENT, VTODO, VJOURNAL, > and VFREEBUSY. Deferred: wouldn't it be useful to have a per-attendee rstatus? --------------26F7C3F5B4C8B04CABA3D569 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

      Thanks Cyrus.

      Some follow up questions below for:

      Part 1 -

          #1 still considering that one

          #4

      Part 2 - #19, 23


      Given the number of changes I've submitted an updated draft with these and the previously noted changes.

      Thanks.


      On 5/20/19 16:12, Cyrus Daboo wrote:
      Hi,
      I am one of the expert reviewers for the IANA iCalendar registries. Below are my comments on draft-ietf-calext-eventpub-extensions-12. This review has focussed solely on the definitions of the new iCalendar elements expected to be published by IANA.

      I have divided up this review into two sections: the first are issues that I think warrant further discussion; the second are issues that need simple corrections.

      Part 1
      ======

      1. Section 6 (SOURCE): Adding a new value type for an existing property is potentially not backwards compatible as existing implementations may be coded to validate that the SOURCE property is only VALUE=URI. Have any tests been done to see if this change will break any current iCalendar implementations making use of SOURCE?
      I guess that was the point of not allowing a default? If they don't know how to handle value=<anything other than uri> then they should ignore it.

      2. Section 8.1 (PARTICIPANT): should a UID property be required for this component? If not required, should it be optional? Or is there some other "primary key" that should be used to identify the same participant across multiple events ("calendaraddress" is not always present)?
      I'm OK with it being required. I hadn't thought of trying to indicate it's the same participant across different events. I guess for example it allows us to know it's the same hockey team for example. Added.


      3. Section 8.1 (PARTICIPANT): why isn't GEO property allowed in the component?
      Added

      4. Section 5.2 (RESTYPE): How does a "remote conference" RESTYPE for a structured resource related to a CONFERENCE property defined by RFC 7986? Shouldn't CONFERENCE be preferred for describing a conference "resource"?
      The intent was not to describe the conference but the resources required for a conference. I guess they could be implied from the conference property

      5. Section 5.3 (ORDER): "This parameter MAY be applied to any property that allows multiple instances". Strictly speaking this should result in the modification of lots of existing iCalendar properties to allow inclusion of this parameter. I presume the WG is OK with not requiring this draft to include all the updated property definitions? Or should this be scoped to only the new properties defined in this draft? I am not sure it is meaningful on properties like ATTENDEE

      Part 2
      ======

      1. Section 6: States "The default value type for this property is URI.". However, RFC 7986, which was the original definition of the property states: "Value Type:  URI -- no default". i.e., the VALUE parameter MUST always be present - there is no default. This draft must not override that behavior. Please fix.
      Fixed

      2. Section 6: I think the Purpose field should include the purpose from RFC 7986. Perhaps this can be re-worded:

         Purpose:  This property provides a reference to information about a
               component such as a participant possibly as a vcard or optionally
               a plain text typed value. It can also be used to identify a URI
               where calendar data can be refreshed from.
      Added text

      3. In Section 6: conformance does not indicate the cardinality of the property. RFC 7986 allows it only once in a VCALENDAR component. What is the cardinality for this new use of it? Also, I prefer the "style" used in RFC 7986 rather than the one using 2119 keywords - but I will leave that up to you.
      Switched to 7986 wording


      4. Section 6: in the Description: "In a resource or participant". I understand that a "participant" means the new "PARTICIPANT" component - I think that should be explicitly described. But what is a "resource" - does that mean a "PARTICIPANT" component that represents a resource? Since this property seems to have differenting interpretations depending on the type of component it is used in, I think it would be better to enumerate all the components and describe the behaviors for each (grouping together where appropriate).

      I've made this more restrictive.

      	In a PARTICIPANT component it may provide a reference to
      	a vcard giving directory information.
      

      5. Section 6: Format definition: the "VALUE" items in the "source = " definition need to be moved to "sourceparam = " to avoid hard-coding the order of parameters. 5545's DTSTART definition shows how that can be done

      Pretty sure I copied that out of some other spec...

      Changed


      6. Section 7.1: no cardinality in Conformance.
      Fixed

      7. Section 7.1: Format definition: s/This parameter is defined/This property is defined/.
      Fixed

      8. Section 7.1: Format definition: The "=" in participanttype should be ":".
      Fixed

      9. Section 7.1: Format definition: Please include a definition for the parameters, even if it is only "otherparam".
      Done

      10. Section 7.2: no cardinality in Conformance.
      Fixed

      11. Section 7.2: Format definition: s/This parameter is defined/This property is defined/.
      Done

      12. Section 7.2: Format definition: The "=" in calendaraddress should be ":".
      Done

      13. Section 7.2: Format definition: Please include a definition for the parameters, even if it is only "otherparam".
      Done

      14. Section 7.3: Format definition: as per #6 above, please move VALUE= definitions into the param.
      Done

      15. Section 7.4: Conformance: "in any iCalendar component". Section 4 shows this component only in a sub-set of others - those should be listed here. Why can't this be used in VJOURNAL or VFREEBUSY?
      Omission - added

      16. Section 7.4: Format definition: as per #6 above, please move VALUE= definitions into the param.
      Done

      17: Section 7.5: Conformance: "in any iCalendar component". Section 4 shows this component only in a sub-set of others - those should be listed here.

      Done
      18. Section 7.5: Format definition: as per #6 above, please move VALUE= definitions into the param. Also, the current definition is wrong - there should not be a "/" after strucresparam.
      Done

      19. Section 7.6: Conformance: please state explicitly that TEXT is the default value.

      Following the example of the others:

          1. Should I remove the default and require VALUE=

          2. Move VALUE= and ENCODING= into the params


      20. Section 8.1: Conformance: "in any iCalendar component". Section 4 shows this component only in a sub-set of others - those should be listed here.
      Fixed

      21. Section 8.1: no cardinality in Conformance.
      Fixed

      22. Section 8.1: Format definition: s/This property is defined/This component is defined/.
      Fixed

      23. Section 8.1: rstatus should probably not be present in this component as it is specific to scheduling of VEVENT, VTODO, VJOURNAL, and VFREEBUSY.

      Deferred: wouldn't it be useful to have a per-attendee rstatus?


      --------------26F7C3F5B4C8B04CABA3D569-- From nobody Mon May 27 22:47:49 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1749A120110; Mon, 27 May 2019 22:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 MwwFvhkqag1E; Mon, 27 May 2019 22:47:45 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 17F2112006B; Mon, 27 May 2019 22:47:44 -0700 (PDT) Received: from prolepsis.kaduk.org (c-24-16-119-19.hsd1.wa.comcast.net [24.16.119.19]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4S5la1F016804 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 May 2019 01:47:39 -0400 Date: Mon, 27 May 2019 22:47:36 -0700 From: Benjamin Kaduk To: Michael Douglass Cc: =?iso-8859-1?Q?=C9ric?= Vyncke , The IESG , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Message-ID: <20190528054735.GR18546@prolepsis.kaduk.org> References: <155824877972.30943.11526489467710509788.idtracker@ietfa.amsl.com> <37f6fcf6-c25e-8bdc-32d7-e7b11d3ab26f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <37f6fcf6-c25e-8bdc-32d7-e7b11d3ab26f@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [calsify] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on__draf?= =?iso-8859-1?q?t-ietf-calext-eventpub-extensions-12=3A_=28with_COMMENT=29?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 05:47:47 -0000 On Sat, May 25, 2019 at 10:55:44PM -0400, Michael Douglass wrote: > Thanks ric > > On 5/19/19 02:52, ric Vyncke via Datatracker wrote: > > > > -- Section 5.4 -- > > > > Please use https://example.org rather than https://schema.org or is it a > > reference, existing URI ? > It's a specific (realistic) example of expected use. Is it OK as is? It's not very realistic IMO if the inline value used doesn't conform to the indicated schema (after base64 decoding). -Ben From nobody Tue May 28 17:08:48 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BC11200D8; Tue, 28 May 2019 17:08:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, daniel.migault@ericsson.com, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2019 17:08:47 -0700 Archived-At: Subject: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 00:08:47 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-calext-eventpub-extensions-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I want to talk some about the redefinition of SOURCE. While I agree that the original definition's applicability is more narrow than it needs to be, that doesn't seem to be enough to convince me that there's enough justification to make it so broad as to provide vcard information about a participant or an event link-back, as opposed to just the canonical source of updates for a given object/component. I must apologize for having essentially not done a search of the WG discussion archives for this topic, and pointers into the archive could help to convince me that this redefinition is a stable, interoperable, and backwards-compatible choice. The example in Section 5.4: STRUCTURED-DATA;FMTTYPE=application/ld+json; SCHEMA="https://schema.org/FlightReservation"; ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy contains an inline value that doesn't seem to decode to a valid FlightReservation JSON object. Perhaps I'm misreading, but the ABNF in Section 7.6 does not seem to allow for an explicit VALUE=TEXT parameter to be given, and the description does not list TEXT as the default value type. (I note that the listed example does include VALUE=TEXT, causing this to rise to a Discuss-level internal inconsistency.) Similarly, the examples in Section 8.1 seem incomplete, since they omit the REQUIRED dtstamp and uid properties. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 The properties defined here can all reference external meta-data which may be used by applications to provide enhanced value to users. This sentence seems to raise my hackles for two reasons: (1) it reads like marketing copy and not a technical specification, and (2) it calls to mind analogies to all the privacy-harming technologies that have become pervasive in HTML mail and the web ecosystem: tracking pixels, call-home URLs, etc.. While I agree that loading remote content can be helpful, it is definitely a dual-use technology; I appreciate that the privacy considerations attempt to cover the risks of remote content. Perhaps there is additional room to nod to those risks at this point in the document. Using STRUCTURED-LOCATION, information about a number of interesting locations can be communicated, for example, address, region, country, postal code as well as other informations such as the parking, restaurants and the venue. [...] nit: "the parking" is incomplete; perhaps "parking availability"? nit: "restaurants" is also incomplete; perhaps "nearby restaurants"? In social calendaring it is often important to identify the active participants in the event, for example a school sports team, and the inactive participants, for example the parents. I share the directorate reviewer's confusion as to what "social calendaring" is. Section 3.1.1 In addition, there will be sponsorship information for sponsors of the event and perhaps paid sponsorship properties essentially advertising local establishments. I'm not sure how much precedent the IETF has for facilitating advertising as a specific goal. Section 3.1.2.1 A meeting may have 10 attendees non of which are co-located. The nit: s/non/none/ current ATTENDEE property does not allow for the addition of such meta-data. The PARTICIPANT property allows attendees to specify their location. nit: PARTICIPANT is a component, not a property. Section 4 Please be more concrete about what actually is changing, e.g., the addition of participantc to eventc/todoc/journalc, as well as the more obvious incremental addition to the properties' ABNF. Making the reader cross-reference to RFC 5545 for each ABNF production is rather unfriendly. Section 5.2 Is a video remote conferencing facility assumed to also provide audio functionality? Section 5.3 nit: "lowest level of ordering" is perhaps ambiguous (though the subsequent clarification is not); I'd suggest just "as being ordered last". Example uses: The ORDER may be applied to the PARTICIPANT-TYPE property to indicate the relative importance of the participant, for example as a sponsor or a performer. For example, ORDER=1 could define the principal performer or soloist. side note: It's not very clear to me that it's going to be possible to assign a complete ordering to all participants once events start getting complicated. There is the option of just leaving a single low-priority "everybody else" bucket and not worrying too hard, but this feels like something easy that gets a quick win but will not be a full solution. (Which, to be clear, is not necessarily bad.) Section 5.5 While I'm sympathetic to not actually putting a full HTML styled description in the example, I'd suggest at least putting in the closing tag. Section 7.1 nit: is there a reason for active participants to be taking a "role" but inactive ones taking a "part"? Section 7.3 It's not clear to me when one would attach an alternative representation to a STYLED-DESCRIPTION rather than just adding the other representation as another STYLED-DESCRIPTION in its own right. Presumably this just means I'm not an iCalendar expert, but maybe there is something more subtle going on here. Section 7.4 Do we want a reference to RFC 7986 again for the LABEL parameter? When used in a component the value of this property provides information about the event venue or of related services such as parking, dining, stations etc.. Does this hold universally for all components (e.g., even PARTICIPANT) or only some of them? I don't understand all the discussion about the "Use of the related parameter", which is presumably just my lack of familiarity with iCalendar in general. But it's surprising that we'd have to worry about timezones and such for events/todos related to a structured *location*. Section 7.5 strucewaval = ( uri / text ) "strucewaval" seems like a typo and does not appear elsewhere in the document. Section 8.1 Conformance: This component can be specified multiple times in a "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component. Description: This component provides information about a participant in an event, task or poll. [...] Why do these two lists have different cardinality? Privacy Issues: When a LOCATION is supplied it provides information about the location of a participant at a given time or times. This may represent an unacceptable privacy risk for some participants. User agents MUST NOT include this information without informing the participant. How is this "informing" supposed to work when the participant is not a human (e.g., an organizational SPONSOR or a sports team)? Also, it seems likely that there may be attributes (parameters) other than location that a given individual may not wish to be disclosed, or at least disclosed globally. In the last example: BEGIN: PARTICIPANT SOURCE;FMTTYPE=text/vcard; this last semicolon should be a colon? http://dir.example.com/vcard/contacts/contact1.vcf PARTICIPANT-TYPE:CONTACT DESCRIPTION:A contact: The last colon here is superflous? END:PARTICIPANT Section 8.2 It's not entirely clear to me that we need this much discussion about schedulable PARTICPANTs -- can't we get most of the way with the status quo of ATTENDEE properties being schedulable, and just noting that for such ATTENDEEs, the matching PARTICIPANT may have additional (e.g., location) information? Section 9.1 This example seems to illustrate a weakness of STRUCTURED-LOCATION, namely that it relies upon the human readaing the LABEL parameter to understand what type of relationship the location has to the event. It seems that calendaring software would be able to present a better interface if there was some structured information available about the type of location, as well as the freeform string of the label. Section 9.2 The time gap between DTSTAMP and CREATED is rather large; is that intended? It might also be helpful to give some indication of the meeting room where the event is nominally occurring, so as to make the "At home" location more clearly a remote location. Section 10 Potential additional security considerations: the target of the CALENDAR-ADDRESS URLs may have access control on them, and not all recipients of the property may be authorized to access the referenced calendar. Such access control is properly a matter for the owner of the calendar in question, but it may still be appropriate to mention it here. Security considerations relating to the "ATTACH" property, as described in [RFC5545], are applicable to the "STRUCTURED-DATA" property. I had a quick look in RFC 5545, and neither the labelled Security Considerations section nor any mention of "ATTACH" (with quotes) seemed to cover such security considerations. What am I missing? When processing HTML content applications need to be aware of the many security and privacy issues as described in the IANA considerations section of [W3C.REC-html51-20171003] nits: this needs at least a comma after "content", and possibly another comma before "as described". Section 11 There may be some privacy considerations relating to the ORDER parameter, as it provides an indication of some entity (the organizer's?) perception of the relative importance of other participants. The addition of location information to the new participant component provides information about the location of participants at a given time. We probably should go a little further and note that this may facilitate tracking of individuals or malicious actions targeted against them at the known location/time pair. From nobody Wed May 29 12:05:30 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 934D41201B3; Wed, 29 May 2019 12:05:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, daniel.migault@ericsson.com, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155915671351.5441.17788073160352746190.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2019 12:05:13 -0700 Archived-At: Subject: [calsify] Roman Danyliw's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 19:05:18 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-calext-eventpub-extensions-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Per the Security Considerations section, [RFC3986] and [W3C.REC-html51-20171003] were helpful. I was hoping to see cautionary text for the potentially danger of handling/parsing arbitrary binaries as allowed by STRUCTURED DATA. I didn’t see it in downstream references. I also tried to find the referenced section suggested by “Security considerations relating to the ‘ATTACH’ property, as described in [RFC5545]” but could not. It’s not the explicit Security Considerations (Section 7 of [RFC5545) or in the definition of Attachment (Section 3.8.1.1 of [RFC5545]). Do you mean Section 3.1.3, Binary Content? Could you please make it clear which section you meant. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Sections 5.1. and 5.2 state “New resource types SHOULD be registered in the manner laid down in this specification.” It would be cleared if you explicitly referenced the relevant IANA section. (2) Section 6. Doesn't the sentence “[t]he SOURCE property defined in [RFC7986] is redefined …” suggests that this document should also officially update RFC7986? (3) Editorial nits: Global. “vcard” and “VCARD” is used interchangeably. Recommend choosing one and being consistent Section 2. Misplaced comma?. s/JSON, [RFC8259]/JSON [RFC8259] Section 3. Typo. s/informations/information/ Section 3.1.2. Typo. s/traveller/traveler/ Section 3.1.2.1. Typo. s/non/none/ Section 7.5. Typo. s/sevices/services/ Section 9.2. Typo. s/plaaning/planning/ From nobody Wed May 29 13:58:42 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B8C120096; Wed, 29 May 2019 13:58:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, daniel.migault@ericsson.com, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155916352061.5560.17495616222314318364.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2019 13:58:40 -0700 Archived-At: Subject: [calsify] Alissa Cooper's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 20:58:41 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-calext-eventpub-extensions-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 7.6: " The format type and schema parameters can be specified on this property and are RECOMMENDED for text or inline binary encoded content information." Doesn't this need to be REQUIRED rather than RECOMMENDED in order for it to improve rather than potentially worsen interoperability? Section 8.1: "User agents MUST NOT include this information without informing the participant." This seems like it needs to say "without the participant's express permission." (As in https://www.w3.org/TR/geolocation-API). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. The abstract should mention the update to RFC 7986 and the introduction should explain what is updated. Section 11: "This specification does not introduce any additional privacy concerns beyond those described in [RFC5545]." This seems untrue given the sentence that follows it, so this should be deleted. From nobody Wed May 29 13:59:41 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C416D1201E2; Wed, 29 May 2019 13:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=M9Vh7yYz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JgsN1NFJ 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 TKWEq_NDb0uX; Wed, 29 May 2019 13:59:29 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6D6120096; Wed, 29 May 2019 13:59:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5872222375; Wed, 29 May 2019 16:59:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 29 May 2019 16:59:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=9 OcQxZMGUoFpIxRyVrgiknAw6BOo6rOT3+TPhGlkw8M=; b=M9Vh7yYztJwg3hgzh 7eyIfK54EI/Hwl1C8yZI5dMKR7ACpTPmSXxtkIsIiuu45FDG4Zwf/La+qAitIpzZ iApS8/wJ9kAcMryCnFKwFfHKYJ5xYJp8Jb+VHqX5Pmcza1/Fn6iyleo3EpXfT2o/ 1R2kiJvEIMaPsd+Iz83Kud5w/Yreem4hBICiyYddoQP7nFSL6KMETEJ0E5t8WEv0 y2oXlrBs6PFMdb8bCQzWEf3lj4m4LAvpUB7jY5nACRR1eJdy6gZuLmFinS/kk8qt q9Nb1G5oLwBVxBm90aJzbC1DMIoEaAnrd8r6+w2I4A+P4pT3gpv04A89YSwY4qPn qbjDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=9OcQxZMGUoFpIxRyVrgiknAw6BOo6rOT3+TPhGlkw 8M=; b=JgsN1NFJSmEU/s1SfN4JNRJp6+UA/9c61rXrd94n8m3Tlqz3l5rRsesKe IdFXuE4d8eJKquKPbizxJbj4aEi7bqcIQ0d02ybdT5b/SLnu/5z/mERoK0o3npB5 waxkFFVEwWhf8tThprpXlfPpJAnDdOaa2gAY+MyM38a9ptLXRrADfe1RvOE9xqSB g8A0pIRoz3Diocpn8KK4qEOaNu22R10gMCclAN4huf9s2uVHAWmr7tyBENOadTAo 0MEGgffp4MayLgxnrteJbfZQ62BvmH2TL90sAAzNhamqSw0KRi2daIgp3xD6jXrh ucy9yPIqcFwu4tQrWfWMMcjZc6LdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvjedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekfeenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.83]) by mail.messagingengine.com (Postfix) with ESMTPA id 75CC380061; Wed, 29 May 2019 16:59:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155644551863.20986.430303451434247977@ietfa.amsl.com> Date: Wed, 29 May 2019 16:59:22 -0400 Cc: gen-art@ietf.org, draft-ietf-calext-eventpub-extensions.all@ietf.org, ietf@ietf.org, calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <95DC1C99-63C4-4EF2-BE0D-061E168AAC73@cooperw.in> References: <155644551863.20986.430303451434247977@ietfa.amsl.com> To: Dan Romascanu X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [calsify] [Gen-art] Genart last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 20:59:32 -0000 Dan, thanks for your review. I entered a DISCUSS ballot on a couple of = unrelated points and asked the authors to respond to you. Alissa > On Apr 28, 2019, at 5:58 AM, Dan Romascanu via Datatracker = wrote: >=20 > Reviewer: Dan Romascanu > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-calext-eventpub-extensions-12 > Reviewer: Dan Romascanu > Review Date: 2019-04-28 > IETF LC End Date: 2019-04-29 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > This is a clear and detailed document updating RFC 5545 to include new > properties and components to iCalendar. The document is READY for = publication. > I found a number of minor issues as well as a few nits which should be > clarified and fixed in the further editing process. >=20 > Major issues: >=20 > Minor issues: >=20 > 1. The document uses the term 'event' which has many meanings in many = contexts. > It would be useful to include or reference a definition of what is = meant by > 'event' in the context of iCalendar >=20 > 2. The Abstract mentions that some of the updates are useful for = social > networking. I could not find any support for this claim in the text, = with the > exception mybe of mentioning 'social calendaring' in Section 3, which = is also a > vague term (or at least I do not know where it is defined or referred = in the > IETF). I suggest to either clarify, or drop these mentions. >=20 > 3. In Section 3: >=20 >> Using STRUCTURED-LOCATION, information about a number of interesting > locations can be communicated, for example, address, region, = country, >=20 > Isn't it rather 'supplementary information about the location' than > 'information about a number of interesting locations'? >=20 > 4. Inconsistent use/non-use of keywords. >=20 > In 5.2: >=20 > 'This parameter MAY be specified on STRUCTURED-RESOURCE > and provides a way to differentiate multiple properties.' >=20 > while in 5.5: >=20 > 'This property parameter can be specified on any > property when the value is derived from some other property or > properties.' >=20 > I suggest to decide on a consistent use of either MAY or 'can'. >=20 > Nits/editorial comments: >=20 > 1. In Section 2: >=20 >> This is a > better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259] > handles such structures and allows richer definitions. >=20 > Fix grammar (plural) >=20 > 2. In the use cases in Section 3, there are many optional parameters, = and the > use of conditional in the text may be more appropriate. >=20 > For example in 3.1.1: >=20 > 'In addition, there will be sponsorship information for > sponsors of the event' >=20 > better >=20 > 'In addition, there may be sponsorship information for > sponsors of the event' >=20 > 3. In Section 3.1.2.1 >=20 > s/A meeting may have 10 attendees non of which are co-located/A = meeting may > have 10 attendees, none of which are co-located/ >=20 > 4. I do not know if Appendix B will be kept, but in case it will be, = there is a > typo in: >=20 >> Fix PARTTYPE/PARTICPANT-TYPE inconsistency >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art