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

[Alexey Melnikov <[e-mail]>]

Hi Michael,

Some specific comments above. Please post -12 at your earliest 
convenience so that I can progress the document.

On 29/03/2019 04:49, Michael Douglass wrote:
>
> 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?
>
RFC 8259 for JSON, <https://www.w3.org/TR/2008/REC-xml-20081126/> for XML
>
>>
>> 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".
This still mean that there is a need for a normative reference. Use the 
W3C document.

>> 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
I think I missed "text" above, so this is a non issue.
>>
>> 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.
I don't mind, but if it remains you need to add an explanation.
>>
>>    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?
>
Yes..
>
> That's beginning to sound like an update to 5546
>
Understanding of privacy concerns has evolved since RFC 5546 was 
published. You just need to mention possible issues here. I am quite 
certain that you will get a blocking DISCUSS comment during IESG review 
if you don't.

>> 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
>
If the procedure is clear for IANA, then it is fine with me.