Subject: [Jmap] Review of draft-ietf-jmap-blob-09

From: Jim Fenton <[email-masked]>
Date: Tue, 15 Mar 2022 16:51:48 -0700

I went through jmap-blob-09 today and it looks like you have addressed 
nearly all of my comments on -07; thanks!

A couple of residual or new items:

Abstract: (RFC8620) -> [RFC8620]

The new draft seems to avoid the use of ‘catenate’ that was used 
extensively in -07. Good, because at least for me, ‘catenate’ is 
rarely used (while ‘concatenate’ is common); you had me running for 
the dictionary. But there are a couple of lingering uses that are 
probably not intended:

* Section 4.1, 5th paragraph from end, “…the catenate itself is 
invalid…”
* Section 4.1, penultimate paragraph, “…catenate sources might be 
extended…”

Section 5, last paragraph, chosen DataSources -> chosen data sources

You might also want to run this through idnits; it found a few other 
things.

-Jim

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 15 Mar 2022 20:10:19 -0400

Thanks! I'll do that later tonight.. I'll see if I can sneak in a -10 before the session, though my slides from obviously address both -09 and the fixes since. Also gonna implement just to make sure it makes sense.

Bron.

On Tue, Mar 15, 2022, at 19:51, Jim Fenton wrote:
> I went through jmap-blob-09 today and it looks like you have addressed nearly all of my comments on -07; thanks!
> 
> The new draft seems to avoid the use of ‘catenate’ that was used extensively in -07. Good, because at least for me, ‘catenate’ is rarely used (while ‘concatenate’ is common); you had me running for the dictionary. But there are a couple of lingering uses that are probably not intended:
> 
>  * Section 4.1, 5th paragraph from end, “…the catenate itself is invalid…”
>  * Section 4.1, penultimate paragraph, “…catenate sources might be extended…”
> You might also want to run this through idnits; it found a few other things.
> 
> -Jim
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: nelkins alan <[email-masked]>
Date: Wed, 16 Mar 2022 12:52:18 +0000 (UTC)

Got it.

Sent from Yahoo Mail for iPhone

On Tuesday, March 15, 2022, 19:11, Bron Gondwana <[email-masked]> wrote:

#yiv8960052730 p.yiv8960052730MsoNormal, #yiv8960052730 p.yiv8960052730MsoNoSpacing{margin:0;}#yiv8960052730 p.yiv8960052730MsoNormal, #yiv8960052730 p.yiv8960052730MsoNoSpacing{margin:0;}Thanks! I'll do that later tonight.. I'll see if I can sneak in a -10 before the session, though my slides from obviously address both -09 and the fixes since. Also gonna implement just to make sure it makes sense.

Bron.

   - Section 4.1, 5th paragraph from end, “…the catenate itself is invalid…”   

   - Section 4.1, penultimate paragraph, “…catenate sources might be extended…”   

-Jim

_______________________________________________
Jmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jmap

---

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 19 Mar 2022 12:10:17 +0100

> Abstract: (RFC8620) -> [RFC8620]

If I do this, idnits complains:

  ** The abstract seems to contain references ([RFC8620]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

>  * Section 4.1, penultimate paragraph, “…catenate sources might be extended…”

This is fixed.  Thanks for noticing them.

> Section 5, last paragraph, chosen DataSources -> chosen data sources

Yep, fair - DataSource is the object, but in that context it should just be words rather than the object definition.

> You might also want to run this through idnits; it found a few other things.
The main thing was long lines for the registry tables.  Was there anything else that isn't an artifact of the parser assuming square brackets in JMAP object syntax are references?

Bron.