Telechat Review of draft-ietf-calext-jscontact-profiles-11
review-ietf-calext-jscontact-profiles-11-artart-telechat-kyzivat-2026-01-31-00
| Request | Review of | draft-ietf-calext-jscontact-profiles |
|---|---|---|
| Requested revision | No specific revision (document currently at 14) | |
| Type | Telechat Review | |
| Team | ART Area Review Team (artart) | |
| Deadline | 2026-02-03 | |
| Requested | 2026-01-29 | |
| Authors | Robert Stepanek , Mario Loffredo | |
| I-D last updated | 2026-03-13 (Latest revision 2026-02-17) | |
| Completed reviews |
Genart IETF Last Call review of -09
by Behcet Sarikaya
(diff)
Artart IETF Last Call review of -09 by Paul Kyzivat (diff) Artart Telechat review of -11 by Paul Kyzivat (diff) |
|
| Assignment | Reviewer | Paul Kyzivat |
| State | Completed | |
| Request | Telechat review on draft-ietf-calext-jscontact-profiles by ART Area Review Team Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/art/UU2lSXvR1Z4uQbe9mEZZGb3FVJk/ | |
| Reviewed revision | 11 (document currently at 14) | |
| Result | Ready w/issues | |
| Completed | 2026-01-31 |
review-ietf-calext-jscontact-profiles-11-artart-telechat-kyzivat-2026-01-31-00
Reviewer: Paul Kyzivat Review result: Ready with Issues I am the assigned ARTART reviewer for this Internet-Draft. Document: draft-ietf-calext-jscontact-profiles-11 Reviewer: Paul Kyzivat Review Date: 2026-01-31 IETF LC End Date: 2025-11-25 IESG Telechat date: 2026-02-03 Summary: This draft is on the right track but has open issues, described in the review. This document has resolved most of the issues I raised on the -09 version for Last Call. One of those was a NIT: long lines. This too has been resolved. But the resolution has raised another issue. The long lines were in Table 1, in an example of how to define the properties of a profile. In version -09 the table had columns to define all possible profile properties that might need to be specified. This yielded a table wider that the maximum RFC line length. Version -11 has "solved" this by removing a column that was not needed for this specific example. While this solved the problem for this example, it doesn't solve the problem for someone who wants to register a profile that needs all the columns. It seems unwise to leave it to future registrants to devise a solution. I suggest that this document expand its example to include all the possible profile properties, and specify a suitable way to document them for a registration.