Subject: Re: [arch-d] I-D Action: draft-iab-for-the-users-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Nov 2019 14:29:17 +1300

Hi,

There's a lot of good stuff in this draft. Just one point caught my eye:

> 4.6.  Deprioritising Internal Needs
> 
>    There are a number of needs that are very visible to us as
>    specification authors, but should explicitly not be prioritised over
>    the needs of end users.
> 
>    These include: convenience for document editors, IETF process
>    matters, and "architectural purity".

I suggest making the last point: "architectural purity" for its own sake.
There are certainly many cases where the argument *for* architectural
purity is the principle of least astonishment, which directly benefits
the user experience.

Another point that occurs to me is whether the draft should say something
about user interface issues. Of course that topic is out of IETF scope,
but the protocol model may affect the UI in ways that have great
impact on the user.

Regards
   Brian Carpenter

On 18-Nov-19 13:43, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Architecture Board IETF of the IETF.
> 
>         Title           : The Internet is for End Users
>         Author          : Mark Nottingham
> 	Filename        : draft-iab-for-the-users-01.txt
> 	Pages           : 11
> 	Date            : 2019-11-17
> 
> Abstract:
>    This document explains why the IAB believes the IETF should consider
>    end users as its highest priority concern, and how that can be done.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iab-for-the-users/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-iab-for-the-users-01
> https://datatracker.ietf.org/doc/html/draft-iab-for-the-users-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-iab-for-the-users-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2019 09:30:57 +0800

> On 18 Nov 2019, at 9:29 am, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

I like that - thanks.

> but the protocol model may affect the UI in ways that have great

I think that's a *great* area for discussion.

> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

--
Mark Nottingham   https://www.mnot.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2019 23:09:55 +1300

> I think that's a *great* area for discussion.

I was thinking of POP3 and IMAP as a case in point. They differ semantically
in a way that is definitely not obvious or intuitive for the normal user.
In one case, fetching a message to device A either deletes the message
from the server, or marks it as already downloaded, so device B can never
fetch it. In the other case, fetching a message to device A leaves it
available for device B, but of course deleting it from device A also makes
it unavailable for device B.

Mixing usage of POP3 and IMAP for the same user+server can be even more
confusing.

Now, I know that IMAP is considered superior and more modern etc., but
this is still a real confusion in the real world.

Any other examples?

   Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Nov 2019 07:31:15 -0800

> On 18 Nov 2019, at 9:29 am, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi,
> 

Current “user needs” aren’t always benefit the system as a whole nor the needs of users in the future.

"Architectural purity” can be (and should be) representing the latter and need not be considered “internal”.

> about user interface issues. Of course that topic is out of IETF scope,

I’m trying to understand how that makes any sense for a group that is writing about protocols and communication architectures.

I’m assuming it comes from the “the API is out of scope” error that was made many years ago - which confuses the API *instance* with the upper layer interface architecture. RFC793 gives a great example of the latter (the abstract “user commands’). In subsequent work, the absence of that interface as IETF work was a mistake.

I hope this doc isn’t trying to propagate that error.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2019 13:01:51 +1300

> "Architectural purity” can be (and should be) representing the latter and need not be considered “internal”.

I agree. The point is quite subtle, but I thought that "for its own sake"
covered it. 

> I’m trying to understand how that makes any sense for a group that is writing about protocols and communication architectures.

We don't design UIs. But what we do constrains and biases the choices that the UI designer makes. 
 
> I’m assuming it comes from the “the API is out of scope” error that was made many years ago - which confuses the API *instance* with the upper layer interface architecture. RFC793 gives a great exa…

I think the argument is indeed quite similar. The protocol design constrains and biases the API design. And I don't think "out of scope" is really such a bright line. The POSIX API follows RFC3493 quite closely, as does WinSock. Sadly POSIX doesn't support RFC3542, which is a fail.

Please look at draft-ietf-anima-grasp-api-04 for a current example.

   Brian