p≡p I-Ds (IETF Internet-Drafts)
 
 
 
Go to file
Bernie Hoeneisen 6323d8b2af initial version 2019-10-02 17:01:45 +02:00
ietf-lamps-hp-requirements removed "depending on solution" as this applies to any known solution 2019-07-22 16:56:41 -04:00
lamps-header-protection version rollover 2019-07-05 22:55:58 +02:00
medup added more names 2019-07-23 16:36:58 -04:00
medup-requirements changed title, added reference to new pearg I-D, updated open issues 2019-10-01 11:37:36 +02:00
medup-ux-considerations initial version 2019-10-02 17:01:45 +02:00
misc added open issues 2019-07-08 09:49:44 +02:00
pearg-analysis remove the MEDUP requirements, specifically for distributed private messaging applications 2019-10-01 18:40:49 +02:00
pep Remove review files. 2019-07-09 22:15:01 +02:00
pep-email Remove review files. 2019-07-09 22:15:01 +02:00
pep-handshake Prepare for publish and housekeeping 2019-07-07 23:12:12 +02:00
pep-keyreset remove dependencies on E-D keysync 2019-07-04 19:36:59 +02:00
pep-keysync s/Button/button/g && remove hyphen; => unify. 2019-07-13 14:53:09 +02:00
pep-rating prepare for publish and housekeeping 2019-07-07 21:48:23 +02:00
pep-trustwords Remove review files. 2019-07-09 22:15:01 +02:00
shared initial version 2019-10-02 17:01:45 +02:00
.hgignore refined 2019-06-24 23:33:02 +02:00
README.txt Dito 2019-06-29 01:34:36 +02:00

README.txt

Contents
========

This repository contains different p≡p and other (e.g., MEDUP) 
Internet-Drafts, some already submitted in different versions, others under 
development and yet to be submitted in a first version -- to the IETF 
Internet-Drafts repository:

https://www.ietf.org/id-info/

In each directory an Internet-Draft (I-D) is provided, e.g.:

* pep (pEp's general draft)
* pep-email (pEp for email)
* pep-handshake (pEp's method to authenticate peers)
* pep-keysync (pEp's method to synchronize secret keys)
* pep-rating (pEp's rating system to signal privacy levels)
* pep-trustwords (pEp's replacement for fingerprints)

Tools
=====

The mandatory ASCII or XML files for submission are created using
the kramdown-rfc2629 tool creating the XMLv2 format initially described as 
RFC2629 (obsoleted by RFC7749):

https://tools.ietf.org/html/rfc7749

Please install kramdown-rfc2629, ruby and xml2rfc through your package 
system or directly from the respective sites:

* https://github.com/cabo/kramdown-rfc2629
* https://www.ruby-lang.org/
* https://xml2rfc.tools.ietf.org/

You can also install kramdown-rfc2629 through the ruby gem packaging system 
if your packaging system doesn't know anything about this tool:

https://rubygems.org/

Structure and contents of each I-D
==================================

Each p≡p I-D consists of the following raw files:

* ${name_of_the_draft}.mkd
* Makefile

Abstracts should give a rough overview of what the I-D is about: this is to 
happen over 5-10 lines. Less than 3 and more than 20 lines should be avoided.

The main content goes into the middle section: make sure you also provide 
"Introduction" and "Security Consideration" subsections. For the latter, 
please check RFC3552 to see what aspects to consider:

https://tools.ietf.org/html/rfc3552

A back section can be used for appendix information like listings or 
information which provides additional information, but which is not 
mandatory to understand the I-D.

Basic metadata (e.g., authors' names, email addresses and the draft title), 
but also references (including RFCs, by instance) are made available through
a special syntax at the beginning of the Markdown file.

Makefiles contain the build instructions to generate the I-Ds in the required
ASCII and xml2rfc v2 forms accepted by the IETF submission system. Additionally,
they also create HTML versions.

By default, revision number (REV) is set to "00": make sure to increment this
as IETF contributions are furthered.


Version Control System (Mercurial)
==================================

Most important commands:

* Download repository / initialization:
  1) hg clone https://pep.foundation/dev/repos/internet-drafts/

* Update local directories to latest repository state:
  1) hg pull
  2) hg update

  Note: Merge handling (by ``hg merge'') may be required to take care of
  (if indicated after hg update)

* Upload local changes to repository 

  Important: To avoid conflicts, _always_ update the local directories
  to the latest repository state (see commands in last bullet point)
  _before_ doing a commit!

  1) hg commit -m "<Changelog, short description of changes>" [ <filename> ]
  2) hg push

More information:

* https://www.mercurial-scm.org/
* https://www.mercurial-scm.org/wiki/Tutorial