Re: [Jmap] [art] [Last-Call] Artart last call review of draft-ietf-jmap-contacts-06

[John C Klensin <[e-mail]>]

--On Monday, April 8, 2024 06:40 +0200 Carsten Bormann <[e-mail]>
wrote:

> On 8. Apr 2024, at 06:06, Bron Gondwana
> <brong=[e-mail]> wrote:
>> 
>> I suggest saying something like this in the security
>> considerations:
>> 
>> […] SHOULD […]
> 
> The security considerations section is not the place to make
> normative statements about the protocol. What *is* the security
> consideration that would lead to such a set of statement?

Carsten, I thought about that too but decided it was a separate issue
that the authors and WG could work out with each other and the
community.  I share your preference for avoiding normative statements
there, but it is a principle that has been violated enough times in
the past that it is hard to claim that it is a hard rule.

A tweak to the "experience has shown" text I suggested to Bron could
clearly  suggest a security consideration.   Or one could pull the
text Bron suggested out (with or without my addition) and put it
somewhere else, perhaps in the little-used "Internationalization
Considerations" section.   As he suggested, I think we should leave
it to the authors to make a more specific proposal rather than trying
micro-edit the document on this list.

> (I also think that this would be a rather heavy late change of the
> protocol. Has the "Freeform Class as defined in PRECIS" been
> examined to actually be useful for this application? [Quick, does
> it say all the right things about bidirectional strings for contact
> information?] Why is the server only to be restricted about setting
> "names" while the client is restricted about displaying any
> strings?)

I think Bron covered the more substantive part of this but it seems
to me that, if our model is that AD review after publication is
requested followed by IETF Last Call are actually the first points at
which we expect the IESG and the broader community to carefully
review the document, this is no such thing as a too-heavy late change
if those reviews spot a non-trivial deficiency or other problem. 

As I have said in other contexts, if the only substantive changes
that can be made after IETF LC starts are to prevent earthshaking
catastrophes, then we should stop claiming IETF Stream documents
represent IETF consensus and start being more clear that they
represent the consensus of a (possibly quite homogeneous) WG that the
IETF community has had a chance to review and check.

best,
   john