notation data

Werner Koch wk at
Tue Oct 4 09:15:08 CEST 2005

On Sat, 01 Oct 2005 18:14:37 +0200, Marcus Brinkmann said:

> 1. GPGME currently does pass through the notation data unchanged.
>    This means patterns are evaluated (like %k etc).  As I can convert
>    a string with escape charactere transparently in GPGME, no action
>    in GnuPG is required to make this behaviour optional.  But I think
>    it would be convenient to have a flag that switches it off (it can
>    be a pseudo flag for the notation data).

Makes sense to me.

> 2. There is no way to pass arbitrary binary data for the notation
>    name(!) and value to GnuPG.  So currently only strings are allowed.

No problem.  No such notation data has been defined and common
practise for the NAME is to use an email address, so it is anyway
rather limited.  No need to make proliferation of binary names
etc. easier using gpgme.

> 3. There is no way to specify a notation name that starts with a '!'
>    character without setting the critical flag (and I am not sure if
>    "!!name at foo" will even work).  GPGME could detect this and return

See above.  It is not a good idea to do this.

>    an error, but currently it doesn't.  Furthermore, if more flags are
>    defined by the standard, names that used to work may start to

If there will ever be new flags, we can change this.  You might want
to error out if the name starts with a '!'. 

> 4. There is no way to read out the critical flag.  GnuPG should issue
>    a NOTATION_FLAGS status message after NOTATION_DATA with the flags
>    of the notation.

Okay, we need to do something about it.  NOTATION_FLAGS is probably
the easiest way.

> 5. GnuPG automatically sets the human-readable flag.  This seems to be
>    wrong to me, as RFC2440 says:

>        First octet: 0x80 = human-readable. This note is text, a note
>                            from one person to another, and has no
>                            meaning to software.

I recall that there was a discussion in the WG on that issue but
without any concrete results. 



More information about the Gnupg-devel mailing list