I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-calext-subscription-upgrade-13
Reviewer: Paul Kyzivat
Review Date: 2025-04-11
IETF LC End Date: 2025-04-14
IESG Telechat date: ?
Summary:
This draft is on the right track but has open issues, described in the
review.
ISSUES: 8
NITS: 4
1) ISSUE: Ambiguity
In section 3.1, the phrase "When a server receives an invalid token it
MUST..." seems unclear about what you mean by "invalid". I guess you
mean a token that is syntactically valid but is not semantically
meaningful to the server.
E.g., the syntax of Sync-Token allows any sort of URI, but each server
presumably only issues a small subset of the possible tokens, and only
accepts tokens it issued. A URI of an unexpected type would presumably
be unacceptable to the server.
I suggest changing this statement to:
"When a server receives a token it didn't issue it MUST..."
or
"When a server receives a token it doesn't understand it MUST..."
2) ISSUE: Terminology
I see both Component and Entity used in this document, I think as
synonyms, but I'm not sure. I find this confusing. RFC5545 has the same
problem, but seems to favor Component. And it also uses MIME entity as
something different.
If these terms are indeed intended to be synonyms then please use one
consistently. If not, please define *your* meaning for Entity.
3) ISSUE: Clarity/Precision
Section 3.2 says:
"On the first enhanced GET after the entity has been deleted a skeleton,
but valid, entity will be returned with STATUS: DELETED. The receiving
client is free to remove the entity or update its STATUS property.
On subsequent fetches the entity will not be returned."
The use of "first" here is dubious. IIUC, the decision of what to return
is based on the Sync-Token presented by the client. A client could
potentially query multiple times using the same Sync-Token value, and
get DELETED multiple times, rendering "first" incorrect.
My understanding is that if the server receives a Sync-Token issued
prior to the deletion, then it returns the entity with DELETED. If it
receives a token issued after the deletion, then it does not return the
entity. (This implies that the server must indefinitely retain a record
of deleted entities.)
Please reword to better explain this.
4) ISSUE: Units for paging
In section 3.3, regarding paging of responses, my understanding is that
the limit is in units of components. But any individual component can be
of unbounded size. How is this sort of limit helpful?
(For an example of a component of unbounded size, section 3.1 says "a
recurring event and its overrides are treated as a single entity." There
can be any number of overrides.)
I would think that it would be more useful for the limit to be in units
of octets.
5) ISSUE: Consistency of examples
Example 3 in section 3.5, which shows a failure, uses the same
Sync-Token ("data:,1234567") as the prior examples, that were
successful. It seems wrong for the same server to return both success
and failure for this token. I suggest using a different token for this
example. Perhaps even a different URI type.
6) ISSUE: Missing definitions
In section 4, what is the difference between DELETED and CANCELLED?
RFC5545 also has a discussion of deleted components. It also fails to
define either of them, or the distinction between them.
Please clearly define these.
7) ISSUE: Revising Syntax defined in another document
Section 4.1 provides a complete replacement for the ABNF 'STATUS' rule
defined in RFC5545.
It is unfortunate that simply adding another value for the STATUS
property requires such a large update. However it does seem unavoidable
because RFC5554 made no provision for extension of these values.
While doing this I suggest making additional changes so that future
changes won't require doing this again. You did part of the necessary
work by defining a new Status registry. But there remains more to do.
The ABNF should be revised to make provision for future additions. For
example:
statvalue-event = "TENTATIVE" ;Indicates event is tentative.
/ "CONFIRMED" ;Indicates event is definite.
/ "CANCELLED" ;Indicates event was cancelled.
/ "DELETED" ;Indicates event was deleted.
/ iana-token ;Other IANA-registered status
(There are probably other odds and ends to complete this process.)
?) Security Concerns
The new link relations defined in section 7.* seem to introduce new
security concerns that are not mentioned in section 8.
I am not a security expert, so I leave it to the security review to
consider this further.
8) ISSUE: IANA Considerations for the STATUS property
A revised template for STATUS property is needed, as specified in
section 8.2.3 of RFC5545. It needs to change the Reference field to
refer to this document.
9) NIT: Clarity and precision
Section 2 says:
"These LINK headers will be delivered when a client carries out a HEAD
request targeting the URL of the resource."
These won't always be present in HEAD requests. I suggest qualifying
this statement. E.g.:
"The server MAY offer alternative access methods by including LINK
headers in the response when a client submits a HEAD request targeting
the URL of the resource."
10) NIT: Terminology
In section 3, I question the choice of the name "Enhanced GET" for this
protocol. It seems that this protocol only enhances GET in one way: for
subscriptions. Using this name here will be confusing if other
enhancements to GET are defined. And elsewhere in the document the term
"subscribe-enhanced-get" is used. I suggest consistently using
"subscribe-enhanced-get", or perhaps something like "Calendar GET".
11) NIT: Missing ABNF reference
Sections 6.1 & 6.2 specify these new abnf rules:
pref-subscribe-enhanced-get = "subscribe-enhanced-get"
pref-limit = "limit" BWS "=" BWS 1*DIGIT
But there is no reference in the document to either of these rule names.
So what is the purpose of defining these rules?
Section 10.2 registers the *values* from these rules, but makes no use
of the rule names.
12) NIT: Things reported by IdNits
The IdNits tool reported several things. These two seem significant:
-- 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
https://trustee.ietf.org/license-info for more information.)
** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)
[END]
_______________________________________________
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org
