Subject: [calsify] Ben Campbell's Discuss on draft-ietf-calext-extensions-03: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 28 Jun 2016 18:29:24 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-calext-extensions-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-extensions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

These should be easy to fix:

- This draft pretty clearly updates RFC 5545. But it isn't marked as
doing so.

- Sections 8.3 and 8.4 define new registries, but do not state a
registration policy. They refer to RFC 5545 section 8.2.6. That section
talks about registering new values, but does not appear to talk about new
registries. I think it's likely that the registration procedures from
5545 section 8.2.1 actually apply. If so, these sections should cite
that.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-5.11, description: There's citations for tel, http/https and data url
schemes. The "chat" scheme conspicuously lacks a citation. Since you use
xmpp in the example, maybe a citation to RFC 5122 (the xmpp: URI) would
be in order? Also, would it make sense to mention SIP URIs?

-6.1, description: Does “... MUST be used for the default behavior” mean
something different than “... MUST be used.”?  (The "default" part seems
to weaken the MUST.

- 6.4: I'm surprised that this section has no mention of use of the
LANGUAGE parameter. I think maybe it should, at least in the example. Or
is this just one of those things an iCal person just knows because it
applies to any use of text value types?

-- In the description: "As a result, clients SHOULD expect to find this
      property parameter present on many different properties"

Why not MUST? Are there reasonable scenarios where a client might choose
not to expect that?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jun 2016 14:46:32 +0100

Hi Ben,
Thank you for your review.

I agree with you. Cyrus?

> 5545 section 8.2.1 actually apply. If so, these sections should cite

Cyrus, I got confused by this as well, so getting a clarification on
what is intended here (or whether this is how iCalendar properties which
are enumerated values get registered) would be great. 

All good comments.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Jun 2016 11:46:04 -0400

Hi Ben,

> - This draft pretty clearly updates RFC 5545. But it isn't marked as

I have already made that change in my working copy in response to earlier 
reviews. I just sent a copy of my current draft in response to another IESG 
review comment.

> 5545 section 8.2.1 actually apply. If so, these sections should cite

Good point. I have now created a new Section 9.3 (was 8.3 in previous 
draft) that has the previous 8.3 and 8.4 as sub-sections. Text within the 
new 9.3 is:

9.3.  Property Parameter Value Registries

   Two new IANA registries for iCalendar elements have been added.
   Additional codes MAY be used, provided the process described in
   Section 8.2.1 of [RFC5545] is used to register them, using the
   template in Section 8.2.6 of [RFC5545].

> be in order? Also, would it make sense to mention SIP URIs?

I've added sip/sips and xmpp as examples. New text:

   Description:  This property specifies information for accessing a
      conferencing system for attendees of a meeting or task.  This
      might be for a telephone-based conference number dial-in with
      access codes included (such as a tel: URI [RFC3966] or a sip: or
      sips: URI [RFC3261]), or it might be for a web-based video chat
      (such as a http: or https: URI [RFC7230]), or a URI for an instant
      messaging group chat room (such as an xmpp: URI [RFC5122]).  If a
      specific URI for a conferencing system is not available, a data:
      URI [RFC2397] containing a text description can be used.

> -6.1, description: Does “... MUST be used for the default behavior”
> mean something different than “... MUST be used.”?  (The "default"
> part seems to weaken the MUST.

Changed to:

    In the absence of this parameter, the default value
      "BADGE" MUST be used.
> applies to any use of text value types?

Appropriate language tagging in iCalendar is a tricky subject. There is no 
single property that defines a default language for the text within an 
iCalendar object, and there is reluctance to add the LANGUAGE parameter to 
every property that has text values due to increase in the size of the data 
that would result. Now that I think about it, it would actually have made 
sense for this specification to define DEFAULT-LANGUAGE as a top-level 
property. Instead, I think we can try doing that in 
<https://tools.ietf.org/html/draft-douglass-calendar-extension-06> which, 
amongst other things, attempts to support multi-lingual iCalendar objects 
(I've just chatted with the author of that draft and he is on board with 
that too). I am hoping that draft will be adopted as follow on work by the 
WG.

In the meantime I propose the following adjustments to this draft:

1) Add languageparam to the ABNF of the CONFERENCE property

2) Add new paragraph to the CONFERENCE property description:

      The "LANGUAGE" property parameter can be used to specify the
      language used for text values used with this property (as per
      Section 3.2.10 of [RFC5545].

3) The LABEL parameter description has the following sentence appended to 
it:

    The "LANGUAGE" property parameter can be
      used to specify the language of the text in the parameter value
      (as per Section 3.2.10 of [RFC5545].

> Why not MUST? Are there reasonable scenarios where a client might choose

I will change to MUST.

-- 
Cyrus Daboo

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 29 Jun 2016 11:22:09 -0500

Hi Cyrus,

All of your responses work for me. I will clear the discuss, under the 
assumption that the proposed changes will make it into a submitted 
update.

Thanks!

Ben.

On 29 Jun 2016, at 10:46, Cyrus Daboo wrote:

> I have already made that change in my working copy in response to 
> earlier reviews. I just sent a copy of my current draft in response to 
> another IESG review comment.
>
> draft) that has the previous 8.3 and 8.4 as sub-sections. Text within 
> the new 9.3 is:
>
> Appropriate language tagging in iCalendar is a tricky subject. There 
> is no single property that defines a default language for the text 
> within an iCalendar object, and there is reluctance to add the 
> LANGUAGE parameter to every property that has text values due to 
> increase in the size of the data that would result. Now that I think 
> about it, it would actually have made sense for this specification to 
> define DEFAULT-LANGUAGE as a top-level property. Instead, I think we 
> can try doing that in 
> <https://tools.ietf.org/html/draft-douglass-calendar-extension-06> 
> which, amongst other things, attempts to support multi-lingual 
> iCalendar objects (I've just chatted with the author of that draft and 
> he is on board with that too). I am hoping that draft will be adopted 
> as follow on work by the WG.
>
> 3) The LABEL parameter description has the following sentence appended 
> to it:
>