[Last-Call] Re: [calsify] Last Call: <draft-ietf-calext-subscription-upgrade-13.txt> (Calendar subscription upgrades) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 01.04.2025 um 00:36 schrieb The IESG:

The IESG has received a request from the Calendaring Extensions WG (calext)
to consider the following document: - 'Calendar subscription upgrades'
   <draft-ietf-calext-subscription-upgrade-13.txt> as Proposed Standard
...

Major issues:

3 Enhanced GET

At least two alternatives come to mind that would not require to
"enhance" GET:

a) Use regular conditional request using ETags, and let the server send
incremental contents based on Etag in "If-None-Match", and let the
response vary by that request header field. See also
https://mailarchive.ietf.org/arch/msg/calsify/_CnkP8Ys5oIK1L-uCETwPFYV2lM/
for more details.

b) Use Range Request with a new range unit suitable for text/calendar
content.


5. Header Field

It seems that
<https://www.rfc-editor.org/rfc/rfc9110.html#considerations.for.new.fields>
were not followed.

For instance, are these examples equivalent?

a)  Sync-Token: "data:,1234567"

b)  Sync-Token: "data:,\1234567"

c)  Sync-Token: "data:,1234567", "data:,1234568"

d)  Sync-Token: "data:,1234568", "data:,1234567"

e)  Sync-Token: "data:,1234567"
    Sync-Token: "data:,1234568"

f)  Sync-Token: "data:
    Sync-Token: 1234567"

Note that using Structured Fields
(https://www.rfc-editor.org/rfc/rfc9651) would help with that.



Other issues:

2. Discovering...

There's no reason why other methods, such as OPTIONS or GET, would not
return these Link relations as well.

6. Preferences

(if actually needed, see above...) both preference names should be made
very specific for this protocol. In particular, "limit" is way to generic.

See also <https://www.rfc-editor.org/rfc/rfc7240.html#section-5.1>.

10. IANA

For header fields, please see
<https://www.rfc-editor.org/rfc/rfc9110.html#field.name.registration>
and <https://www.rfc-editor.org/rfc/rfc9651.html#iana>.



Editorial Nits:

Abstract does not mention the actual protocol extension for GET.

The reference to RFC 7231 needs to be updated.


Best regards, Julian

--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux