Subject: [calsify] draft-ietf-calext-eventpub-extensions-06

From: Daniel Migault <[email-masked]>
Date: Tue, 15 May 2018 13:12:37 -0400

Hi,

draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would like
to sufficient reviews to move the document to the IESG. If you have not yet
commented the document, please provide your feedbacks by May 29 so we can
move the document forward.

Yours,
Calext co-chairs.

[1] https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/

---

From: Daniel Migault <[email-masked]>
Date: Tue, 15 May 2018 23:07:40 -0400

Hi,

Please find some comments. These comments are indicative.

Yours,
Daniel

Abstract:
The header indicates that RFC 5545,and RFC 5546 are updated. This must be
also stated in the Abstract and in the introduction.

1.  Introduction

"""
Current practice is to embed this information as links in the
   description or to add x-properties.
"""

It is not clear to me how to use x-properties. Is it a notation ? In
addition, I am also wondering if this does not designate the LABEL
property. If that is correct, maybe that could be explicitly stated to
better understand section 5.

The conventions needs to be updated according to RFC 8174

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

3.  Typed References

"""
   perhaps
   for indexing or the presentation of additional related information
   for the user.
"""

Thought English is not my natural language, there might be a nit there.

   perhaps
   for indexing or presentating the additional related information
   to the user.
--

"""
Using STRUCTURED-LOCATION, information about a number of interesting
   locations can be communicated, for example, parking, restaurants and
   the venue.  Servers and clients can retrieve the objects when storing
   the event and use them to index by geographic location.
"""

It is not clear from the text that the location information mentioned above
(e.g. address, region, country, postal code) that motivated the
STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also mention
them

Using STRUCTURED-LOCATION, information about a number of interesting
   locations can be communicated, for example, address, region, country,
postal code as well as other informations such as the parking, restaurants
and
   the venue.  Servers and clients can retrieve the objects when storing
   the event and use them to index by geographic location.

---

3.1.2.  Itineraries

"""
The contact information can
   provide detailed information about the booking agent, the airlines
   and car hire companies and the hotel.
"""

Looks to me that there is an additional "and".

5.  New Property Parameters

"""
   This specification makes use of the LABEL property parameter which is
   defined in [RFC7986]
"""

My understanding is that the parameters described in this section apply to
the LABEL property. It seems to me that this is the first time the LABEL
properties and associated parameters are mentioned in the document. In
other words, I have hard time finding where this section is introduced  in
the previous sections such as the introduction. If I am correct, maybe that
could be clarified in the introduction.

It seems to me that the document is structured with a kind of bottom - up
approach. parameters < properties < components. Thus I am wondering if
there are any reasons for not having the Calendar Components at the very
end instead of at the beginning.

I am also wondering if that would not be more easy to read the document
with Participant Types and Resource Types listed within their respective
Properties.

On Tue, May 15, 2018 at 1:12 PM, Daniel Migault <[email-masked]
> wrote:

> Hi,
>
> draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would
> like to sufficient reviews to move the document to the IESG. If you have
> not yet commented the document, please provide your feedbacks by May 29 so
> we can move the document forward.
>
> Yours,
> Calext co-chairs.
>
>
>

---

From: Michael Douglass <[email-masked]>
Date: Wed, 16 May 2018 00:05:15 -0400

On 5/15/18 23:07, Daniel Migault wrote:

> It seems to me that the document is structured with a kind of bottom - 
> up approach. parameters < properties < components. Thus I am wondering 
> if there are any reasons for not having the Calendar Components at the 
> very end instead of at the beginning.
>
> I am also wondering if that would not be more easy to read the 
> document with Participant Types and Resource Types listed within their 
> respective Properties.
That's possible. I was following the structure of 5545 which arranges 
things that way.
>
>
>
>
> On Tue, May 15, 2018 at 1:12 PM, Daniel Migault 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We
>     would like to sufficient reviews to move the document to the IESG.
>     If you have not yet commented the document, please provide your
>     feedbacks by May 29 so we can move the document forward.
>
>     Yours,
>     Calext co-chairs.
>
>
>
>     [1]
>     https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>     <https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/>
>
>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Wed, 16 May 2018 01:33:59 -0400

Thank you for the comments - I've submitted a new draft to address these 
and just realised I didn't address any of Robert's issues.

I'll deal with those in day or so.

On 5/15/18 23:07, Daniel Migault wrote:
> The header indicates that RFC 5545,and RFC 5546 are updated. This must 
> be also stated in the Abstract and in the introduction.
Some text added
> better understand section 5.
I've changed the text to refer to non-standard properties and provided a 
reference to the section in 5545.

LABEL is a parameter used to provide a human-readable label for 
properties - something like the alt attribute in html - so no - that is 
a different usage

>    "OPTIONAL" in this document are to be interpreted as described in
Done
>    for indexing or presentating the additional related information
Changed to:

perhaps for indexing or the
         presenting of additional related information for the user.
> It is not clear from the text that the location information mentioned 
> above (e.g. address, region, country, postal code) that motivated the 
> STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also 
> mention them
>
>
>    locations can be communicated, for example, address, region, 
> country, postal code as well as other informations such as the 
> parking, restaurants and
Done
> Looks to me that there is an additional "and".
Removed
> My understanding is that the parameters described in this section 
> apply to the LABEL property.. It seems to me that this is the first 
> time the LABEL properties and associated parameters are mentioned in 
> the document. In other words, I have hard time finding where this 
> section is introduced  in the previous sections such as the 
> introduction. If I am correct, maybe that could be clarified in the 
> introduction.
LABEL is a parameter - it turns up in the ABNF for a number of the 
properties defined here. The phrase "property parameter" was pulled out 
of that spec - from 5545 as well. "LABEL parameter" is a little clearer 
I think. I'll try that.
> document with Participant Types and Resource Types listed within their 
I see what you mean now. Makes sense.