(should it
be marked as 'Updates RFC 5545'?). I did not see that addressed. It would
be nice to get an answer, but I do not believe this is a show-stopper.
A new -04 version of the draft has just been published with your review
issues addresse
and defines new properties and elements
that bring into the standard extension elements added by vendors into
their specification.
Yes you are right, this does need to "Update" 5545. I will fix that.
--
Cyrus Daboo
___
Gen-art mailing
r each update and will likely have to be
removed by the RFC editor when they get to process it.
Section 4.1.4 says: "If a client only needs data for only one, ..."
There is an extra "only", please drop the first one.
Fixed.
Section
of the draft you
reviewed.
Anyway, thanks for your review and I will take a detailed look at it soon.
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
nds CalDAV [RFC4791] to specify how the extended "RRULE"
property can be supported by CalDAV servers and clients.
Would that be better?
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
"real names" in examples, then I would be happy to change to follow that,
but I am not aware of anything like that.
Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been
published as RFC 6352; the RFC Editor will correct this if a new version
of the draft is not re
working copy.
- Section 4, 2nd paragraph. Write ".well-known" within quotes to
facilitate the reading of the text.
Fixed there and other places for consistency.
- Section 5 talks about the prohibition to servers to locate the actual
service in the
Hi Brian,
--On October 16, 2009 9:01:43 AM +1300 Brian E Carpenter
wrote:
I'm happy with the proposed changes, as far as my review
goes. I agree with Marc, it seems correct to verify such
changes in normative requirements with the WG.
Email has been sent to the WG list.
--
Cyrus
are private, shared or
public. Clients SHOULD provide an appropriate warning when changing
access privileges for a private or shared address book with data so as
to allow unauthenticated users access.
Is that reasonable?
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
appen only the first time they do an action, or each time?
SHOULD seems a little strong when the nature of the warning is really going
to be implementation dependent.
That said, if there is consensus for this change, it may be necessary to
explain a little more what "warn
;http://tools.ietf.org/html/draft-ietf-calsify-2446bis-09#section-2.1.3>.
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
extended MKCOL - however, given the ever growing deployments of CalDAV that
is probably not going to happen any time soon.
So, I have changed the title to:
"Using Extended MKCOL as an Alternative to MKxxx Methods"
and changed "replace" to "alternative for" in a couple of places.
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
s an RFC editor note to be
corrected prior to publication.
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
onfusion I ran into.
Yes, that second paragraph can be removed. I'm not sure whether there ought
to be a forward reference to the next section there though.
--
Cyrus Daboo
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
14 matches
Mail list logo
