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

From: Daniel Migault <[email-masked]>
Date: Mon, 6 Aug 2018 13:44:12 -0400

Hi,
Just catching up. Is the current version addressing all comments, or do we
expect another version coming in the few next days ?

Yours,
Daniel

On Wed, May 16, 2018 at 1:33 AM, Michael Douglass <[email-masked]>
wrote:

> 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:
>
> 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.
>
> Some text added
>
>
>
> 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.
>
> 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
>
>
>
> 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].
>
> Done
>
>
> 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.
> --
>
> Changed to:
>
> perhaps for indexing or the
>         presenting of additional related information for 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.
>
> Done
>
> ---
>
> 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".
>
> Removed
>
>
>
>
> 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.
>
> 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.
>
>
> 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.
>
> I see what you mean now. Makes sense.
>
>
>
>
> 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.
>>
>>
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-
>> extensions/
>>
>
>
>
> _______________________________________________
> calsify mailing [email-masked]://www.ietf.org/mailman/listinfo/calsify
>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 6 Aug 2018 13:58:29 -0400

In order to get a rough idea of the consensus to move that draft forward to
the IESG, I would also appreciate your support on approving the document.
Please let us know if you believe the document is ready to be moved
forward.

If you have implemented it, it would also be much appreciate to write the
review.

Yours,
Daniel

On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault <[email-masked]>
wrote:

> On Wed, May 16, 2018 at 1:33 AM, Michael Douglass <[email-masked]
> > wrote:
>
>> 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
>>
>>
>>
>> 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.
>>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 6 Aug 2018 14:52:45 -0400

Hi,

Initiating the shepherd write-up here are my additional comments:

1) running the nits raises some minor issues so please remove the '[' and
']' in the abstract.

OLD:

   This specification updates [RFC5545]  and [RFC5546] by introducing a
   number of new iCalendar properties and components which are of
   particular use for event publishers and in social networking.

NEW:

   This specification updates RFC5545 and RFC5546 by introducing a
   number of new iCalendar properties and components which are of
   particular use for event publishers and in social networking.

2)

I do not see the following reference mentioned in the text. Maybe it could
be removed. If you prefer to keep it, maybe informational may be the right
category for it.

   [W3C.REC-xml-20060816]
              Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20060816, August 2006,
              <http://www.w3.org/TR/2006/REC-xml-20060816>.

3) I do not see the update of RFC 5546 being discussed in the introduction.
Could you please add some text ?

4) IANA section,

I suggest to add the URL to the IANA registry as an informative reference.
https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties

section 12.1.{1,2,3} I would remove the term "Registration" to make sure
the title of the section match the registry. Similarly, I would replace
Property by Properties to match the registries.

Yours,
Daniel

On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault <[email-masked]>
wrote:

> In order to get a rough idea of the consensus to move that draft forward
> to the IESG, I would also appreciate your support on approving the
> document. Please let us know if you believe the document is ready to be
> moved forward.
>
> On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault <
>> Just catching up. Is the current version addressing all comments, or do
>> we expect another version coming in the few next days ?
>>
>> Yours,
>> Daniel
>>
>> On Wed, May 16, 2018 at 1:33 AM, Michael Douglass <
>> [email-masked]> 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
>>>
>>>
>>>
>>> 1.  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

---

From: Michael Douglass <[email-masked]>
Date: Mon, 6 Aug 2018 19:39:52 -0400

Thanks Daniel

I'll try and deal with most of these tonight

On 8/6/18 14:52, Daniel Migault wrote:
> 1) running the nits raises some minor issues so please remove the '[' 
> and ']' in the abstract.
>
> OLD:
>
> I do not see the following reference mentioned in the text. Maybe it 
> could be removed. If you prefer to keep it, maybe informational may be 
> the right category for it.
>
>    [W3C.REC-xml-20060816]
> 3) I do not see the update of RFC 5546 being discussed in the 
> introduction. Could you please add some text ?
>
>
> 4) IANA section,
>
> section 12.1.{1,2,3} I would remove the term "Registration" to make 
> sure the title of the section match the registry. Similarly, I would 
> replace Property by Properties to match the registries.
>
> Yours,
> Daniel
>
> On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     In order to get a rough idea of the consensus to move that draft
>     forward to the IESG, I would also appreciate your support on
>     approving the document. Please let us know if you believe the
>     document is ready to be moved forward.
>
>     If you have implemented it, it would also be much appreciate to
>     write the review.
>
>     Yours,
>     Daniel
>
>     On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         Hi,
>         Just catching up. Is the current version addressing all
>         comments, or do we expect another version coming in the few
>         next days ?
>
>         Yours,
>         Daniel
>
>         On Wed, May 16, 2018 at 1:33 AM, Michael Douglass
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             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.
>
>>             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
>>
>>
>>             1.  Introduction
>>
>>             """
>>             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.
>             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
>>
>>
>>             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
>>             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.
>>
>>             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]
>>             <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/>
>>
>>
>>
>>
>>             [email-masked] <mailto:[email-masked]>
>>             <https://www.ietf.org/mailman/listinfo/calsify>
>
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/calsify>
>
>
>
>

---

From: Michael Douglass <[email-masked]>
Date: Mon, 6 Aug 2018 23:13:48 -0400

>    particular use for event publishers and in social networking.
This appears to be an artifact of xml2rfc - there are no square brackets 
in the XML. Is theer some trick to avoiding them? Here's the source:

This specification updates<xref target='RFC5545'/>   and
<xref target='RFC5546'/>  by introducing a number of new iCalendar

---

From: Michael Douglass <[email-masked]>
Date: Mon, 6 Aug 2018 23:36:19 -0400

>    particular use for event publishers and in social networking.
See previous message - seems to be xml2rfc
Removed
> introduction. Could you please add some text ?
Removed the updates reference. 5546 is mentioned but I don't belieev 
updated in any way.
Done
Done
> Daniel
Thanks - Mike

---

From: Michael Douglass <[email-masked]>
Date: Mon, 6 Aug 2018 23:47:17 -0400

I just posted a version 08 to address the issues in these messages

Thanks - Mike

On 8/6/18 13:44, Daniel Migault wrote:
> Hi,
> Just catching up. Is the current version addressing all comments, or 
> do we expect another version coming in the few next days ?
>
> Yours,
> Daniel
>
>     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.
>
>>     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
>>
>>
>>     1.  Introduction
>>
>>     """
>>     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.
>     I've changed the text to refer to non-standard properties and
>     provided a reference to the section in 5545.
>
>     properties - something like the alt attribute in html - so no -
>     that is a different usage
>>
>>
>>     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
>>     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
>     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.
>>
>>     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.
>>
>>         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]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 7 Aug 2018 08:29:34 -0400

Hi Thanks for the update Michael!

I think the trick is to simply put in the xml:

This specification updates RFC5545  andRFC5546 by introducing a number
of new iCalendar

Yours,
Daniel

On Mon, Aug 6, 2018 at 11:13 PM, Michael Douglass <[email-masked]>
wrote:

> This specification updates <xref target='RFC5545'/>  and<xref target='RFC5546'/> by introducing a number of new iCalendar
>
>
>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 7 Aug 2018 08:37:27 -0400

Hi,

The abstract should also remove the reference to 5546 as the ref has been
removed from header and introduction.

Yours,
Daniel

On Mon, Aug 6, 2018 at 11:36 PM, Michael Douglass <[email-masked]>
wrote:

> On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault <
>>>> I've changed the text to refer to non-standard properties and provided
>>>> a reference to the section in 5545.
>>>>
>>>> country, postal code as well as other informations such as the parking,
>>>> restaurants and
>>>>> 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: Tue, 7 Aug 2018 17:05:07 -0400

The text references 5546 because implementors need to understand how 
this is made backwards compatible with that spec. Shoudl that be an 
informative reference?

e.g.

Section 3.1.1

There may be an iTip [RFC5546] meeting request for the piano tuner
who will arrive before the performance.  Other members of staff may

On 8/7/18 08:37, Daniel Migault wrote:
> Hi,
>
> The abstract should also remove the reference to 5546 as the ref has 
> been removed from header and introduction.
>
> Yours,
> Daniel
>
> On Mon, Aug 6, 2018 at 11:36 PM, Michael Douglass 
>>     1) running the nits raises some minor issues so please remove the
>>     '[' and ']' in the abstract.
>>
>>     OLD:
>>
>>     I do not see the following reference mentioned in the text. Maybe
>>     it could be removed. If you prefer to keep it, maybe
>>     informational may be the right category for it.
>>
>>        [W3C.REC-xml-20060816]
>>                   <http://www.w3.org/TR/2006/REC-xml-20060816
>>     <http://www.w3.org/TR/2006/REC-xml-20060816>>.
>>
>     Removed
>>
>     Removed the updates reference. 5546 is mentioned but I don't
>     belieev updated in any way.
>>
>>     4) IANA section,
>>
>>     <https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties>
>>
>     Done
>>
>>     section 12.1.{1,2,3} I would remove the term "Registration" to
>>     make sure the title of the section match the registry. Similarly,
>>     I would replace Property by Properties to match the registries.
>     Done
>>
>>     Yours,
>>     Daniel
>     Thanks - Mike
>
>>
>>         In order to get a rough idea of the consensus to move that
>>         draft forward to the IESG, I would also appreciate your
>>         support on approving the document. Please let us know if you
>>         believe the document is ready to be moved forward.
>>
>>         If you have implemented it, it would also be much appreciate
>>         to write the review.
>>
>>         Yours,
>>         Daniel
>>
>>             comments, or do we expect another version coming in the
>>             few next days ?
>>
>>             Yours,
>>             Daniel
>>
>>                 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.
>>
>>>                 updated. This must be also stated in the Abstract
>>>                 and in the introduction.
>>                 Some text added
>>>
>>>
>>>                 1. Introduction
>>>
>>>                 """
>>>                 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
>>                 I've changed the text to refer to non-standard
>>                 properties and provided a reference to the section in
>>                 5545.
>>
>>                 label for properties - something like the alt
>>                 attribute in html - so no - that is a different usage
>>>
>>>
>>>                 STRUCTURED-LOCATION are part STRUCTURED-LOCATION.
>>>                    locations can be communicated, for example,
>>>                 address, region, country, postal code as well as
>>>                 other informations such as the parking, restaurants and
>>>                 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.
>>                 "property parameter" was pulled out of that spec -
>>                 from 5545 as well. "LABEL parameter" is a little
>>                 clearer I think. I'll try that.
>>>
>>>                 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.
>>>
>>>                     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]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 7 Aug 2018 22:03:18 +0000

Hi Michael,

So I am not saying that 5546 has to be removed everywhere. What I was mentioning is to have what is being updated coherent across the sections (Header, abstract, intro). Thus I was just suggesting to replace in the abstract:

OLD:
This specification updates [RFC5545] and [RFC5546]
NEW:
This specification updates [RFC5545]

This is what I found currently in the draft:

In the header:
     Updates: 5545 (if approved)
In the abstract:
    This specification updates [RFC5545] and [RFC5546]
In the introduction:
    This document updates [RFC5545]

In the remaining of the document 5546 needs to stay as it is. It is a Standards Track, so a normative reference is appropriated.

I apology for the confusion 😉

Yours,
Daniel

From: Michael Douglass <[email-masked]>
Sent: Tuesday, August 07, 2018 5:05 PM
To: Daniel Migault <[email-masked]>
Cc: [email-masked]
Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06

The text references 5546 because implementors need to understand how this is made backwards compatible with that spec. Shoudl that be an informative reference?

e.g.

Section 3.1.1

The abstract should also remove the reference to 5546 as the ref has been removed from header and introduction.

Yours,
Daniel

On Mon, Aug 6, 2018 at 11:36 PM, Michael Douglass <[email-masked]<mailto:[email-masked]>> wrote:

1) running the nits raises some minor issues so please remove the '[' and ']' in the abstract.

OLD:

NEW:

2)

I do not see the following reference mentioned in the text. Maybe it could be removed. If you prefer to keep it, maybe informational may be the right category for it.

   [W3C.REC-xml-20060816]

3) I do not see the update of RFC 5546 being discussed in the introduction. Could you please add some text ?

Removed the updates reference. 5546 is mentioned but I don't belieev updated in any way.

4) IANA section,

section 12.1.{1,2,3} I would remove the term "Registration" to make sure the title of the section match the registry. Similarly, I would replace Property by Properties to match the registries.
Done

Yours,
Daniel
Thanks - Mike

On Mon, Aug 6, 2018 at 1:58 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
In order to get a rough idea of the consensus to move that draft forward to the IESG, I would also appreciate your support on approving the document. Please let us know if you believe the document is ready to be moved forward.

If you have implemented it, it would also be much appreciate to write the review.

Yours,
Daniel

On Mon, Aug 6, 2018 at 1:44 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
Just catching up. Is the current version addressing all comments, or do we expect another version coming in the few next days ?

Yours,
Daniel

On Wed, May 16, 2018 at 1:33 AM, Michael Douglass <[email-masked]<mailto:[email-masked]>> wrote:

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.

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.
Some text added

1.  Introduction

"""

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

3.  Typed References

"""
   perhaps

   perhaps

"""

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

---

3.1.2.  Itineraries

"""

"""

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.

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.
I see what you mean now. Makes sense.

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/

calsify mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
calsify mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/calsify

_______________________________________________
calsify mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Tue, 7 Aug 2018 23:53:56 -0400

Thanks Daniel.

On 8/7/18 18:03, Daniel Migault wrote:
>
> Hi Michael,
>
> So I am not saying that 5546 has to be removed everywhere. What I was 
> mentioning is to have what is being updated coherent across the 
> sections (Header, abstract, intro). Thus I was just suggesting to 
> replace in the abstract:
>
> OLD:
>
> In the remaining of the document 5546 needs to stay as it is. It is a 
> Standards Track, so a normative reference is appropriated.
>
No need - I appreciate the help getting it right
>
> Yours,
>
> Daniel
>
> *From:*Michael Douglass <[email-masked]>
> *Sent:* Tuesday, August 07, 2018 5:05 PM
> *To:* Daniel Migault <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [calsify] draft-ietf-calext-eventpub-extensions-06
>
>     The abstract should also remove the reference to 5546 as the ref
>     has been removed from header and introduction.
>
>     Yours,
>
>     Daniel
>
>             I do not see the following reference mentioned in the
>             text. Maybe it could be removed. If you prefer to keep it,
>             maybe informational may be the right category for it.
>
>                [W3C.REC-xml-20060816]
>             3) I do not see the update of RFC 5546 being discussed in
>             the introduction. Could you please add some text ?
>
>             section 12.1.{1,2,3} I would remove the term
>             "Registration" to make sure the title of the section match
>             the registry. Similarly, I would replace Property by
>             Properties to match the registries.
>
>         Done
>
>             Yours,
>
>             Daniel
>
>         Thanks - Mike
>
>
>
>                 In order to get a rough idea of the consensus to move
>                 that draft forward to the IESG, I would also
>                 appreciate your support on approving the document.
>                 Please let us know if you believe the document is
>                 ready to be moved forward.
>
>                     Just catching up. Is the current version
>                     addressing all comments, or do we expect another
>                     version coming in the few next days ?
>
>                     Yours,
>
>                     Daniel
>
>                         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.
>
>                             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
>
>                             1. Introduction
>
>                             """
>                             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.
>
>                         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
>
>
>
>                             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
>                             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
>                         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.
>
>
>                             approach. parameters < properties <
>                             components. Thus I am wondering if there
>                             are any reasons for not having the
>                             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]
>                                 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]