Skip to content
This repository has been archived by the owner on Feb 7, 2020. It is now read-only.

Update spec? Or is the version from 2015-08-01 the newest one? #9

Open
RokerHRO opened this issue Dec 4, 2017 · 2 comments
Open

Update spec? Or is the version from 2015-08-01 the newest one? #9

RokerHRO opened this issue Dec 4, 2017 · 2 comments

Comments

@RokerHRO
Copy link

RokerHRO commented Dec 4, 2017

The spect at https://github.com/autocrypt/memoryhole/blob/master/specs/draft-memoryhole.md is incomplete, yet. Is there another, newer, more complete draft / spec somewhere?

If yes, this file should be updated (or replaced by a redirect to the newer spec).
If no, the spec should be finished immediately, so it can be implemented by 3rd party software, too.

What do you think?

@RokerHRO RokerHRO changed the title Update spec? Or is the one from 2015-08-01 the newest one? Update spec? Or is the version from 2015-08-01 the newest one? Dec 4, 2017
@dkg
Copy link
Member

dkg commented Dec 4, 2017

I agree that the spec needs to be updated to be completed. It is not as high a priority as the rest of the autocrypt project, though.

Of you have some time to propose improvements or fixes to the specification as specific patches, that'd be great.

@RokerHRO
Copy link
Author

RokerHRO commented Dec 4, 2017

The over 2 years old draft looks more a rough collection of goals or ideas to me, and not a specification, yet.

So, sure, I can add my own ideas into that draft, but I think it would be far better when someone who knows the original plans / ideas / goals, how "Memory Hole" (I don't like that name, though) shall work, write them down.

My suggestions so far:

  1. "introduction" should contain a "motivation" part, so an impatient reader knows what this document is about. (perhaps the same what is in your "abstract" paragraph above?)
  2. Than I'd continue with some examples, which header lines shall be encrypted, signed, signed & encrypted etc.
  3. After that the formal format description might follow
  4. a section about compatibility with non-MemoryHole clients, transition paths etc.
  5. suggestions how MemoryHole-enabled MUAs should create/display/check MemoryHole & legacy headers

Perhaps if there is an EBNF grammar or the like it could also moved into an appendix.

That's all from me, for now. 🙂

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants