Thanks for the response. A few comments inline. I removed sections that don't
seem to need further comment.
On Jul 22, 2013, at 6:55 AM, Philipp Kewisch <kewisch(_at_)gmail(_dot_)com>
wrote:
On 7/17/13 12:27 AM, Ben Campbell wrote:
[...]
-- 3.2.1.1:
What happens for future versions of vCard? Do you simply use the new version
number, or would we need a new version of this spec? I suspect the latter.
If true, it might be worth mentioning that, or somewhere early in the draft
mention that this spec is for vCard 4.0 only.
I'd love to hear from the WG here, but given vCard 5.0 can at least in theory
be completely different, I think the correct thing to do would be to restrict
this jCard document to 4.x and when 5.x comes around create a revision of the
document. Of course the text could be changed so that its "valid until
revised by another document", in case the changes in 5.x are minor enough
that no change in jCard is needed.
In any case, there should be a text change that any 4.x revision is allowed.
For example, I recently read a suggestion for signed vCards that might use a
version "4.0s".
Pending the opinions of the work group, I'm happy with that approach.
-- sections 3.4.3 and 3.4.4:
Is the included ABNF a quotation of that in the referenced RFCs, or is it
new and authoritative? If the former, it would be helpful to mention that in
the text. (I note you did say that about the ABNF in the appendix).
The ISO specs don't provide a direct BNF for any of their constructs. Instead
they show examples in the form:
Basic format: YYYYMMDD Example: 19850412
Extended format: YYYY-MM-DD Example: 1985-04-12
The ABNF in jCard mimics this format, so it is not new, but given it matches
I guess we could say its authoritative. Unless someone tells me otherwise
(I'm still a bit uncertain when something can be called authoritative), I'll
change it by changing the hangText "ABNF Schema:" to "ABNF Schema
(authoritative):" in both sections.
By "authoritative", I don't mean anything particularly formal. It's really a
matter of where the normative text lies. So, for someone implementing _this_
draft, would you expect them to look at the included ABNF only, or is it a case
of the ABNF being here for convenience but a careful implementor should also
look at the ISO specs?
-- 3.4.11:
If RFC6350 says that use of the timezone offset is NOT RECOMMENDED, can you
elaborate on why it's included here? (I can guess it's because people may
still use it in vCards since it was a "MUST NOT", but it would be good to
say something to that effect in the text.)
oops, I think I meant to say "SHOULD NOT".
There is no other vCard property that uses a utc-offset as a type, so this is
just for the sake of an example. RFC6350 Section 6.5.1 has the details, it
says utc-offset SHOULD NOT be used on a TZ property. The alternative would be
to use an x-property for the example, i.e
["x-clock-offset", {}, "utc-offset", "-05:00"]
Do you think we should use this instead?
I don't have strong feelings either way, other than if you include a "NOT
RECOMMENDED" example, it might be wise to put in a sentence or two giving the
reasoning.
Nits/editorial comments:
-- Section 1, paragraph 1:
Please expand JSON on first mention.
Doing this in the introduction since you reference Section 1, paragraph 1. It
already appears in the abstract, should I expand it there instead/in addition?
I think the general approach is that the abstract doesn't "count" for this
purpose. That is, if you separated the abstract and the body into two different
documents, they should both still make sense.
As the first mention uses "JSON-based", I've reworded these two paragraphs:
OLD:
As certain similarities exist between vCard and the iCalendar data
format [RFC5545], there is also an effort to define a JSON-based data
format for calendar information called jCal [I-D.ietf-jcardcal-jcal]
that parallels the format defined in this specification.
The purpose of this specification is to define "jCard", a JSON format
for vCard data. One main advantage to using a JSON-based format as
defined in [RFC4627] over the classic vCard format is easier
processing for JavaScript based widgets and libraries, especially in
the scope of web-based applications.
NEW:
As certain similarities exist between vCard and the iCalendar data
format [RFC5545], there is also an effort to define a JSON-based data
format for calendar information called jCal [I-D.ietf-jcardcal-jcal]
that parallels the format defined in this specification. The term
JSON describes the JavaScript Object Notation defined in [RFC4627].
The purpose of this specification is to define "jCard", a JSON format
for vCard data. One main advantage to using a JSON-based format over
the classic vCard format is easier processing for JavaScript based
widgets and libraries, especially in the scope of web-based
applications.
That works for me.
[...]
-- 1, paragraph 8:
Sentence Fragment.
The original intent was to make this a list of considerations, but as the
first sentences are full I agree this makes it seem weird. How is this? I'm a
little unsure about the "must not", but since this is just a consideration
for the document and not an order for the consumer I think its ok with this
casing:
OLD:
Ability to handle many extensions to the underlying vCard
specification without requiring an update to this document.
NEW:
Extensions to the underlying vCard specification must not lead to
requiring an update to jCard.
WFM.
[...]
-- 3.2.1.3, Last Paragraph:
RFCTODO? I gather in the IANA section, that may be a placeholder for "this
RFC", but that doesn't seem to fit here.
My intention was to keep the registration template as general as possible,
RFCTODO indeed references "this RFC", I've defined an entity for it in the
source. Do you want me to replace it with "this document" instead? I was
thinking if the registration template is maybe copied out of the document and
gathered somewhere, it would make sense to reference the document by its rfc
number.
By registration template, you are talking about the use in the IANA
Considerations, right? My comment was about its use in sections 3.2.1.3 and 5.
I think it makes sense in the IANA considerations (perhaps with a note to the
RFC Editor to replace it with the actual RFC number), but "this document" would
make more sense in 3.2.1.3 and 5.
[...]