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

[Daniel Migault <[e-mail]>]

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.

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

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.

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.

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.

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.




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.

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

  == Unused Reference: 'RFC3688' is defined on line 1084, but no explicit
     reference was found in the text

  == Outdated reference: draft-ietf-calext-extensions has been published as
     RFC 7986

  ** 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]
> wrote:

> Hi,
>
> This starts a Working Group Last Call for:
> 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]>
> Date: Fri, Apr 21, 2017 at 11:37 PM
> Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-
> extensions-02.txt
> To: [e-mail]
> Cc: [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/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-02
> https://datatracker.ietf.org/doc/html/draft-ietf-calext-even
> tpub-extensions-02
>
> A diff from the previous version is available at:
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>
>