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

[Michael Douglass <[e-mail]>]

Hi Daniel

We're taking a look at the current draft and I hope I can get back later 
this week with a firm response


On 9/26/17 18:07, Daniel Migault wrote:
>
> Hi Michael,
>
> I am wondering if you have completed your implementation and if you 
> believe the draft version 03 is ready to be sent to the IESG. If so, I 
> will have a final review and ship the document.
>
> Yours,
>
> Daniel
>
> *From:*Michael Douglass [mailto:[e-mail]]
> *Sent:* Thursday, May 04, 2017 5:01 PM
> *To:* Daniel Migault <[e-mail]>; [e-mail]
> *Subject:* Re: [calsify] I-D Action: 
> draft-ietf-calext-eventpub-extensions-02.txt
>
> I think I will remove the STRUCTURED-RESOURCE property from the draft 
> along with RESTYPE
>
> That was added at a time we were active with resource extensions to 
> vcard and the assumption was that a registry of resource types would 
> come out of that.
>
> That work has been restarted recently but we probably need to rethink 
> the approach. It's possible that the PARTICIPANT component will work 
> instead of a special property for resources.
>
> We can always bring out a later extension to reintroduce that property 
> if we feel it's needed.
>
> I also noticed that I should have specified the uid property as a 
> required property for PARTICIPANT.
>
> On 5/4/17 11:01, Daniel Migault wrote:
>
>     Hi Michael,
>
>     Thanks for the update. The only way I see to address the nits, is
>     to write in plain text RFC5545 in the abstract and use the
>     reference <xref tyarget=””/> in the introduction. I guess the nits
>     tool looks at [.*] to list references.
>
>     Yours,
>
>     Daniel
>
>     *From:*calsify [mailto:[e-mail]] *On Behalf Of
>     *Michael Douglass
>     *Sent:* Thursday, May 04, 2017 10:55 AM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [calsify] I-D Action:
>     draft-ietf-calext-eventpub-extensions-02.txt
>
>     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
>         <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/
>
>             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-eventpub-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 <http://tools.ietf.org>.
>
>             Internet-Drafts are also available by anonymous FTP at:
>             ftp://ftp.ietf.org/internet-drafts/
>
>             _______________________________________________
>             calsify mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/calsify
>
>
>
>
>
>         _______________________________________________
>
>         calsify mailing list
>
>         [e-mail] <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/calsify
>