[calsify] AD review of draft-ietf-calext-eventpub-extensions-10

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 29 October 2018 12:37 UTC

Return-Path: <alexey.melnikov@isode.com>
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 12F83130F05 for <calsify@ietfa.amsl.com>; Mon, 29 Oct 2018 05:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMqlyIg-LcLX for <calsify@ietfa.amsl.com>; Mon, 29 Oct 2018 05:37:25 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7C612D4EA for <calsify@ietf.org>; Mon, 29 Oct 2018 05:37:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1540816644; d=isode.com; s=june2016; i=@isode.com; bh=ouz5RksC4qmFpeMQK8EFJ3+/TXXDwVwTyU//4Sw8pbA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kv6+14YwUcR523BLumkhOahVi3d9yzTVPtvU3LkxRZvs2t2stwIOE+7qBFwsxqO3BAUrYn /TtC/fSt6AjFsY812DTjBafYh4HPVo2/flYS7mps39SNxcJiDDLiKJWdj8d3M4+YF0VOMJ EbGuagP4xTsFwOx1A++oYX/i3xRIw4E=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <W9b=BAArGzfC@waldorf.isode.com>; Mon, 29 Oct 2018 12:37:24 +0000
To: Michael Douglass <mikeadouglass@gmail.com>
Cc: calsify@ietf.org
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <009b5762-3b36-61c7-86a4-716391b6ed43@isode.com>
Date: Mon, 29 Oct 2018 12:37:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/koB9BxT9AMzYdweVn6wPr_HCnhs>
Subject: [calsify] AD review of draft-ietf-calext-eventpub-extensions-10
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2018 12:37:27 -0000

Hi,

I've done my review of the document. Other people found some of the same 
issues, so you might have already fixed some of them.

Also note that I might ask for an extra review from people more familiar 
with use of geo-location in IETF protocols.


In Section 3: XML and JSON need Informative References.


In 7.3:

Due to use of RFC 2119 "SHOULD": "text/html" needs an Normative 
Reference, most likely to HTML5.


In 7.6:

    Property Name:  STRUCTURED-DATA

    Purpose:  This property specifies ancillary data associated with the
       calendar component.

This is rather vague and I think this has implications for Security 
Considerations (so you should mention something there), because anything 
can be stuffed here, including executable content.

    Value Type:  TEXT, BINARY or URI

But the ABNF:

      sdataprop   = "STRUCTURED-DATA" sdataparam
                        (":" text) /
                        (
                          ";" "ENCODING" "=" "BASE64"
                          ";" "VALUE" "=" "BINARY"
                          ":" binary
                        ) /
                        (
                          ";" "VALUE" "=" "URI"
                          ":" uri
                        )
                        CRLF

doesn't include TEXT "value" choice

8.1.  Participant

    Component name:  PARTICIPANT

    Purpose:  This component provides information about a participant in
       an event or optionally a plain text typed value.

What does "or optionally a plain text typed value" mean here? This is a 
component, not a single property.

    Format Definition:

    This property is defined by the following notation:

      participantc  = "BEGIN" ":" "PARTICIPANT" CRLF
                    partprop *alarmc
                    "END" ":" "PARTICIPANT" CRLF

Is inclusion of "alarmc" intentional? (If it is, that is fine. I just 
think I check.)

    Example:

    The following is an example of this component.  It contains a SOURCE
    property which points to a VCARD providing information about the
    event participant.

                      BEGIN:PARTICIPANT
                      PARTICIPANT-TYPE:PRINCIPAL_PERFORMER

PRINCIPAL_PERFORMER is not defined as a valid value for PARTICIPANT-TYPE.

SOURCE:http://dir.example.com/vcard/aviolinist.vcf
                      END:PARTICIPANT


    The following is an example for the primary contact.

                      BEGIN: PARTICIPANT
                      SOURCE;FMTTYPE=text/vcard;
http://dir.example.com/vcard/contacts/contact1.vcf
                      PARTICIPANT-TYPE:PRIMARY-CONTACT

PRIMARY-CONTACT is not defined either.

                      DESCRIPTION:A contact:
                      END:PARTICIPANT



In Section 9.1:

    STRUCTURED-LOCATION;LABEL="The venue":
     http://dir.example.com/venues/big-hall.vcf
    STRUCTURED-LOCATION;LABEL="The venue":
     http://dir.example.com/venues/parking.vcf

Should different instances have different LABEL values?



11.  Privacy Considerations

I think this section needs to talk about unintended exposure of Geo 
location.



12.2.  New Registration Tables

    This section defines new registration tables for PARTICIPANT-TYPE and
    RESTYPE values.  These tables may be updated using the same
    approaches laid down in Section 8.2.1 of [RFC5545]

Section 8.2.1 of [RFC5545] implies that IANA registration procedure is 
"Expert Review"
or "Specification Required" (which implies "Expert Review"). Please 
clarify this for IANA here.


Best Regards,

Alexey