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

[Daniel Migault <[e-mail]>]

Great Thanks!
Yours,
Daniel

On Wed, Sep 27, 2017 at 4:44 AM, Michael Douglass <[e-mail]>
wrote:

> 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]
> <[e-mail]>]
> *Sent:* Thursday, May 04, 2017 5:01 PM
> *To:* Daniel Migault <[e-mail]>
> <[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]
> <[e-mail]>] *On Behalf Of *Michael Douglass
> *Sent:* Thursday, May 04, 2017 10:55 AM
> *To:* [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:
>   ------------------------------------------------------------
> ----------------
>
>      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]> 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-
> 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.
>
> 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
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> calsify mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/calsify
>
>
>
>
>
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>
>