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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Oct 2018 12:37:21 +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

---

From: Michael Douglass <[email-masked]>
Date: Mon, 29 Oct 2018 13:43:06 -0400

Thanks for this. I'll be travelling the next few days but I'll try to 
address them as soon as possible

On 10/29/18 08:37, Alexey Melnikov wrote:
> 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.
>
>
> Considerations (so you should mention something there), because 
> anything can be stuffed here, including executable content.
>
> What does "or optionally a plain text typed value" mean here? This is 
> a component, not a single property.
>
>    Format Definition:
>