Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-02.txt

[Michael Douglass <[e-mail]>]

Thanks for the comments. I've published an updated version 03 and there 
are some comments below.

A couple of particular points that need further work:


   ** The abstract seems to contain references ([RFC5545]), which it
      shouldn't.  Please replace those with straight textual mentions of the
      documents in question.

Is there a guide as to when and when not a refeence?

Also the RESTYPE parameter needs more discussion


On 4/30/17 15:18, Daniel Migault wrote:
> Hi,
>
> Please find my comments regarding the current version. The document is 
> in good shape.
>
> Yours,
> Daniel
>
> 1.  Introduction
>
>
> "Formats such as VCARD are likely to be most useful." I think we need 
> some explanation. Is the VCARD used by the organizer or participant of 
> the event ? If that is the case, it would be clearer to mention it 
> explicitly.
Tried to expand a little
>
> "The following properties and components are defined in this 
> specification". As there are two kind of objects being defined, it 
> would be clarifying for the reader to specify for each item below what 
> category they belong to. My understanding is that only participant is 
> a component others are properties.
I've split off participant as a separate paragraph
>
> 2.  Components and properties
>
> "In a break with this 'tradition' this specification introduces some 
> of these extensions as components rather than properties."
>
> My reading is that components is not used as the iCal terminology 
> here. More specifically, this is not an iCal component. If that is the 
> case, maybe we could use another term. I am trying to find one but 
> agree this is not easy.
At one point I thought we would have multiple components. I've reduced 
it to referring to the one component
>
> 3.  Typed References
>
> """
>    These properties are designed to handle common use cases in event
>    publication.  It is generally important to provide information about
>    the organizers of such events.  Sponsors wish to be referenced in a
>    prominent manner.  In social calendaring it is often important to
>    identify the active participants in the event, for example a school
>    sports team, and the inactive participants, for example the parents.
> """
>
> I also have the impression that properties is not associated to teh 
> ICal properties. In fcat I see Participant as a component. In this 
> case saying the participant components and associated properties seems 
> to be clearer to me  at least.
Left over with the move from PARTICIPANT as a property to a component. 
I've made that paragraph specific to PARTICIPANT
>
> 5.2.  Restype
>
> """
>       Description:  This parameter MAY be specified on STRUCTURED-RESOURCE
>       and provides a way to differentiate multiple properties.
>
>       Values for this parameter are taken from the values defined in
>       [todo].  New resource types SHOULD be registered in the manner
>       laid down in that specification
> """
>
> [todo] needs to be completed.
Yes - There was work on a vcard resource draft which was expected to get 
ahead of this one. That didn't happen.  We'll need some discussion on 
where to go with that.
>
> 5.3.  Order
>
> """
>    Description:  The ORDER parameter is OPTIONAL and is used to indicate
>       the relative ordering of the corresponding instance of a property.
>       Its value MUST be an integer greater than or equal to 1 that
>       quantifies the order.  Lower values correspond to a higher level
>       of ordering, with 1 being the highest.
> """
>
> I would like to make sure and explicit that ordering is performed from 
> low to high value or the reverse.
>
Tried to get rid of some of the higher/lower language

I also found one or 2 issues myself.

Property PARTTYPE has 2 names - should be PARTICIPANT-TYPE

Property SCHEDULE-ADDRESS - definition specified value as iana-token. 
Should be cal-address

Property SCHEDULE-DATA - specified a data type of TEXT only - but it 
should be TEXT, BINARY or URI

Missed format type out of the descriptive text for STYLED-DESCRIPTION

Component PARTICIPANT
Priority was missing from the format definition
Had structuredaddress instead of scheduleaddress
>
>
> Follows the nits provided by the datatracker:
>
> nits:
> idnits 2.14.01
>
> /tmp/draft-ietf-calext-eventpub-extensions-02.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
> http://trustee.ietf.org/license-info):
> ----------------------------------------------------------------------------
>
>      No issues found here.
>
>   Checking nits according to 
> http://www.ietf.org/id-info/1id-guidelines.txt:
> ----------------------------------------------------------------------------
>
>      No issues found here.
>
>   Checking nits according to http://www.ietf.org/id-info/checklist :
> ----------------------------------------------------------------------------
>
>   ** There is 1 instance of too long lines in the document, the 
> longest one
>      being 1 character in excess of 72.
>
>   ** The abstract seems to contain references ([RFC5545]), which it
>      shouldn't.  Please replace those with straight textual mentions 
> of the
>      documents in question.
Is this referring to things like

This specification also defines a new STRUCTURED-DATA property for
iCalendar [RFC5545] to allow for data that is directly pertinent to


Is there a guide as to when should I use a reference and when not?
>
>   -- The draft header indicates that this document updates RFC5545, 
> but the
>      abstract doesn't seem to directly say this.  It does mention RFC5545
>      though, so this could be OK.
>
>   -- The draft header indicates that this document updates RFC5546, 
> but the
>      abstract doesn't seem to mention this, which it should.
>
>
>   Miscellaneous warnings:
> ----------------------------------------------------------------------------
>
>      (Using the creation date from RFC5545, updated by this document, for
>      RFC5378 checks: 2008-10-31)
>
>      (Using the creation date from RFC5546, updated by this document, for
>      RFC5378 checks: 2008-07-14)
>
>   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>      have content which was first submitted before 10 November 2008.  
> If you
>      have contacted all the original authors and they are all willing 
> to grant
>      the BCP78 rights to the IETF Trust, then this is fine, and you 
> can ignore
>      this comment.  If not, you may need to add the pre-RFC5378 
> disclaimer.
>      (See the Legal Provisions document at
> http://trustee.ietf.org/license-info for more information.)
>
>   -- The document date (April 21, 2017) is 9 days in the past.  Is this
>      intentional?
>
>
>   Checking references for intended status: Proposed Standard
> ----------------------------------------------------------------------------
>
>      (See RFCs 3967 and 4897 for information about using normative 
> references
>      to lower-maturity documents in RFCs)
>
>   == Unused Reference: 'RFC2434' is defined on line 1079, but no explicit
>      reference was found in the text
Deleted
>
>   == Unused Reference: 'RFC3688' is defined on line 1084, but no explicit
>      reference was found in the text
Deleted
>
>   == Outdated reference: draft-ietf-calext-extensions has been 
> published as
>      RFC 7986
>
Fixed
>   ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
>
>
>      Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments 
> (--).
>
>      Run idnits with the --verbose option for more detailed 
> information about
>      the items above.
>
> On Sun, Apr 30, 2017 at 2:11 PM, Daniel Migault 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>     This starts a Working Group Last Call for:
>     https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>     <https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/>
>
>     Please provide your comments / reviews by  May 14.
>
>     Yours,
>     Daniel
>
>
>     ---------- Forwarded message ----------
>     From: <[e-mail] <mailto:[e-mail]>>
>     Date: Fri, Apr 21, 2017 at 11:37 PM
>     Subject: [calsify] I-D Action:
>     draft-ietf-calext-eventpub-extensions-02.txt
>     To: [e-mail] <mailto:[e-mail]>
>     Cc: [e-mail] <mailto:[e-mail]>
>
>
>
>     A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>     This draft is a work item of the Calendaring Extensions of the IETF.
>
>             Title           : Event Publishing Extensions to iCalendar
>             Author          : Michael Douglass
>             Filename        : draft-ietf-calext-eventpub-extensions-02.txt
>             Pages           : 28
>             Date            : 2017-04-21
>
>     Abstract:
>        This specification introduces a number of new iCalendar properties
>        and components which are of particular use for event publishers and
>        in social networking.
>
>        This specification also defines a new STRUCTURED-DATA property for
>        iCalendar [RFC5545] to allow for data that is directly pertinent to
>        an event or task to be included with the calendar data.
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
>     <https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/>
>
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-02
>     <https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-02>
>     https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-02
>     <https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-02>
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-02
>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-02>
>
>
>     Please note that it may take a couple of minutes from the time of
>     submission
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>     <ftp://ftp.ietf.org/internet-drafts/>
>
>     _______________________________________________
>     calsify mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/calsify
>     <https://www.ietf.org/mailman/listinfo/calsify>
>
>
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify