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

[Michael Douglass <[e-mail]>]

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.
>
>
> 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
>
>