Subject: [Jcardcal] (no subject)

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 22 Aug 2013 07:10:38 +0000

Hi Philipp, Barry, all,

Herewith I would like to give some suggestions about resolving Barry's "grouping" comments (see below):

Section 3.2.1.3, "Grouping of Properties":

OLD:
   [RFC6350] Section 3.3 defines a grouping construct that is used to
   group related properties together.  To eliminate the need for an
   extra group syntax in jCard, thus unifying the general syntax with
   that of jCal, this specification introduces a "group" parameter, that
   holds the group name.  The parameter MUST NOT be used in vCard as per
   [RFC6350], it is merely registered to reserve the parameter, avoiding
   collisions.
NEW:
   In vCard [RFC6350] related properties can be grouped together using a 
   grouping construct. The grouping is accomplished by adding a prefix to
   the property name, which consists of the group name followed by a dot.

   In jCard the same grouping is achieved through a "group" parameter, 
   that holds the group name. In jCard a property name therefore MUST NOT
   be prefixed by a group name.

   The "GROUP" parameter MUST NOT be used in vCard as per [RFC6350], it is
   merely registered to reserve the parameter, avoiding collisions.
END

Section 3.2.1.3.1 "Group Conversion Rules":

OLD:
   In jCard, the parameter's value is a single opaque string.
   Conversion rules are as follows:

   o  From vCard to jCard, the group construct (see [RFC6350],
      Section 3.3, Page 7) is removed.  In its place, the GROUP
      parameter is added (lowercased, as any other parameter).  Its
      value is a string corresponding to the group name.  The name's
      case MUST be preserved intact.

   o  From jCard to vCard, the reverse procedure is performed.  The
      GROUP parameter MUST NOT appear in the resulting vCard.
NEW:
   In jCard, the parameter's value is a single opaque string.
   Conversion rules are as follows:

   o  From vCard to jCard, the group construct (see [RFC6350],
      Section 3.3, Page 7) is removed.  In its place, the "group"
      parameter is used.  Its value is a string corresponding to
      the group name.  The name's case MUST be preserved intact.

   o  When converting from jCard to vCard, the value of the "group" 
      parameter followed by a dot is prefixed to the property name, 
      and the "group" parameter is discarded. The "GROUP" parameter
      MUST NOT appear in the resulting vCard.
END

<QUOTE>
* You say that the group name's case MUST be preserved; why? vCard says that 
group names are case-insensitive, so why aren't group names put into lowercase,
just as property names are?
</QUOTE>

I have checked RFC 6350. Although it says explicitly that property names and parameter names are case-insensitive, I could not find text about the case-insensitiveness of group names. I can imagine implementations considering the group names case-insensitive, but it seems not to be mandatory. Hence not touching the case of group names seems reasonable.

What do you think?

Best regards,
Bert

---

Barry Leiba's COMMENT:
I was quite confused by the whole "grouping" thing the first time I read it,
but eventually got over that. I think it could be worded better, and I ask you
to take a look at that. Feel free to contact me off list if you'd like me to
help, which I'll be happy to do. Here are some points:

* In vCard, the grouping is accomplished by prefixing the property name with 
"groupname.", and that should be noted here, if for no other reason than to
make it clear that the prefix is NOT included in the property name in the first
array element. Something about that, with a citation to this section, should
be up there in the numbered list ("The property name specified here does not
include any group names; see Section 3.2.1.3, and [RFC6350], Section 3.3.")

* This isn't about "eliminating the need for an extra group syntax in jCard". 
This could have been done with the prefix on the property name, just as in
vCard. Just say that in jCard, the "group" parameter is used to encode the
group name, which was specified as a property-name prefix in vCard.

* In 3.2.1.3.1, I find it confusing to use "GROUP" in uppercase, and then to 
say it gets lowercased "as any other parameter" (and it doesn't help that you
haven't talked about how to encode parameters yet -- this is part of the
organizational problem).

* You say that the group name's case MUST be preserved; why? vCard says that 
group names are case-insensitive, so why aren't group names put into lowercase,
just as property names are?

* In the jCard to vCard conversion of the group name, I wouldn't say "the 
reverse is performed", because there's only one step you're omitting. Just say
that the value of the "group" parameter is prepended with a "." to the property
name, and that the "group" parameter is discarded.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Aug 2013 07:51:18 -0400

I'll read this later today.  For now, just this:

> I have checked RFC 6350. Although it says explicitly that property names
> and parameter names are case-insensitive, I could not find text about the
> case-insensitiveness of group names. I can imagine implementations
> considering the group names case-insensitive, but it seems not to be
> mandatory. Hence not touching the case of group names seems reasonable.

>From RFC 6350:

   group = 1*(ALPHA / DIGIT / "-")
   name  = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME"
         / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL"
         / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE"
         / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES"
         / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP"
         / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML"
         / iana-token / x-name
     ; Parsing of the param and value is based on the "name" as
     ; defined in ABNF sections below.
     ; Group and name are case-insensitive.

Note the last line.

Barry

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 23 Aug 2013 01:23:36 +0000

Hi Barry,

<QUOTE>
>    group = 1*(ALPHA / DIGIT / "-")
...
</QUOTE>

Ah, yes, I missed that one.

If we mandate changing to lower case when converting from vCard to jCard, as we do with property names, I guess we may similarly require conversion to upper case when converting back.

Then we have this with tandem conversion:

(vCard) MyGroup.NAME
-> (jCard) ["name", {"group":"mygroup"}, ...]
-> (vCard) MYGROUP.NAME

Indeed this is semantically equal, but the camelcasing is lost. Not sure if that is a problem.

On the other hand, section 3.3 about parameters says:

<QUOTE>
   The name of the parameter MUST be in lowercase, the original case of the parameter value MUST be preserved.
</QUOTE>

Since we are treating group names as a parameter to the "group" parameter, this could be used as an argument to preserve the case.

If we mandate group names in jCard to be in lower case, how will the parser respond to group names that contain capitals? Reject the jCard due to a syntax error, or should the parser be lenient and consider the capitals as if they are in lower case? I think having "true" case sensitiviness (i.e. "group":"mygroup" != "group":"MyGroup") in jCard would be unhelpful, as there is no way to convert it to vCard without losing semantics. But the lenient parser would internally still have to convert the group name from jCard to lower (or upper) case, irrespective of how it is coded.

This all leads for me to a slight preference to maintain the case of the group name, although SHOULDs would be fine. I guess we need to explictitely state that, like in vCard, in jCard group names are case insensitive. I would also be fine with saying nothing about case conversion, and just stating that jCard group names are case insensitive.

What do you think?

Best regards,
Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Barry Leiba
> Sent: 2013年8月22日 19:51
> To: Bert Greevenbosch
> Cc: Philipp Kewisch; [email-masked]
> Subject: Re:
>