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

[Michael Douglass <[e-mail]>]

Hi Alexey- sorry I missed this. Some questions and comments below:

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.

The text I have is

these extensions as a component rather than a property.  This is a
better match for the way XML and JSON handles such structures and
allows richer definitions.

This is just a reference to the hierarchical nature of XML and JSON 
rather than any particular data representation. What should I be 
referencing?

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

I have:

resource is not given by the "FMTTYPE" parameter.  If the media
type remains unknown, calendar applications SHOULD treat it as
type "text/html".




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

Yes - hangover from earlier. Changed to

This component provides information about a participant
in an event or task.

> 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.)
That I can't remember - it has the flavor of per-user properties. 
However I can remove it.
>
>    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
Changed to PERFORMER and CONTACT
>
>
>
> 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?
Done in v-11
>
>
>
> 11.  Privacy Considerations
>
> I think this section needs to talk about unintended exposure of Geo 
> location.
>
Could you elaborate - are we talking about geo location of participants?

That's beginning to sound like an update to 5546

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

And it looks like that section has an error. It states...

    designated expert and published in an RFC.  A Standards Track RFC is
    REQUIRED for the registration of new value data types that modify
    existing properties, as well as for the registration of participation
    status values to be used in "VEVENT" calendar components.

partstat is used for tasks so it should really have been less specific.

Returning to your comment...

I duplicated the approach taken in e.g. 
https://tools.ietf.org/html/rfc6638 so I think that the text ought to be 
fine. However - I have to admit I hadn't fully absorbed the implications 
so I do need to send emails to the specified lists


>
>
> Best Regards,
>
> Alexey
>
>