Subject: Text canonicalization

From: [email-masked]
Date: Wed, 5 Dec 2001 09:59:15 -0800

A few days ago an issue arose on a cryptography mailing list about
a failing PGP signature on a software package being distributed.
The problem was traced to the fact that the signature was in text mode
on this binary package.  However it raises some issues in the OpenPGP
spec treatment of text mode signatures.

Section 5.2.1 of RFC2440 describes the processing for signatures on text
documents as "The signature is calculated over the text data with its
line endings converted to <CR><LF> and trailing blanks removed."
There are two problems with this.

The first is that it does not make clear what constitutes line endings.
In PGP we treat CR LF, CR, and LF all as line endings and convert each
one to CR LF.  Each of these is used as a line ending on one of the
architectures we support; CR LF on Windows, CR on Macintosh, and LF on
Unix.  We don't restrict the conversion to just native line endings for
two reasons.  First, in a true text document you will have only native
line endings so supporting the others will have no harmful effects; and
second, sometimes you run into text documents with non-native line endings
(because they were transferred in binary mode from another architecture)
and by transforming those line endings as well you increase the chances
of verifying a signature correctly.

I recommend that we specify this canonicalization rule.

The second issue relates to removing trailing blanks.  This is an error in
the spec, as was pointed out by Ulf M=F6ller less than a month before RFC
2440 issued.  Unfortunately in the busy time before the RFC this comment
was overlooked and the spec issued with this error.  No version of PGP has
ever removed trailing blanks in canonicalizing a text document.  (They are
ignored for *clearsigned* text documents, but that is another matter.)

This issue has caused problems for people from time to time since the RFC
has issued.  I recommend that we solve the problem by changing the spec
to conform to how PGP has always worked.  We should eliminate the words
"and trailing blanks removed" from the section above.

Comments?

Hal Finney
Network Associates

---

From: Florian Weimer <[email-masked]>
Date: 05 Dec 2001 21:07:29 +0100

[email-masked] writes:

> one to CR LF.

What about the other line ending characters?  With Unicode (or even
ISO-8859-x close to an EBCDIC environment), there a few more
characters which could end a line.

What about systems such as VMS with out-of-band signalling for line
endings?

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: Werner Koch <[email-masked]>
Date: Thu, 06 Dec 2001 18:37:06 +0100

> a failing PGP signature on a software package being distributed.

Yet another wu-ftpd bug ;-)

> The first is that it does not make clear what constitutes line endings.

We are talking about text documents and imho it is cleary defined what
makes up a line ending:  ANSI defined fopen(3) to take an optional
mode flag "b" to prevent translation of local line endings.

Anyway, this encoding transformation should not go into OpenPGP but to
the next upper layer (MIME), so I consider textmode a compatibilty
trick for PGP 2 - rfc3156 tries to sort out all these issues and it
does not make sense to change OpenPGP just for this.  Well, a note
that textmode should be avoided is appropriate.

> "and trailing blanks removed" from the section above.

I am not in favor of this.  Bugs should not be fixed by changing a
standard.  RFC2440 has been released more than 3 years ago.

  Werner

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 Dec 2001 14:00:41 -0800

In computer science, there are some interesting unsolved problems. A number
of them revolve around semantic issues -- what does data mean -- as opposed
to syntactic issues.

One of these is the notion of text, as opposed to raw data. There are
others (like, for example the unsolved question of what a digital signature
means). I'm going to blither about text, and its relevancy to OpenPGP in
this missive.

In the dim and ancient past, everyone had their own character set.
Gradually, there came to be standard character sets. Arguably, ASCII was
the first standard character set. Then, over the years, it was enhanced to
ISO Latin-1 (ISO 8859-1), and then all the 8859 follow-ons for blocks of
extra characters. I find it charming that for example that ISO Latin-5 (ISO
8859-5) is Cyrillic. There are also lots of other quasi-standard character
sets that are enhancements on ASCII. Then there are all the interesting
ones for Asian languages, and so on and so forth, leading up to Unicode and
ISO 10646, which in theory should eventually be *the* standard character
set.

But in all of this, there's been no standardization of what either the
syntax or semantics of a "line end" is. I'm going to stay away from the
semantics issue, as fun as that could be, because it's really not relevant.
(That discussion would cover how a line end differs between languages that
go left-to-right and right-to-left, and then progress into how you deal
with vertical lines, too.)

There are at least four different ways to denote a line end. For the
purposes of the discussion, I'm going to assume that when a line ends, you
start writing at the left margin, and down one line. I'm doing this for no
other reason than that's what I'm using now. These four mechanisms that I
can think of are:

* Two characters, one that says to go all the way left, one that says go
down one line. The "standard" way to do that is with a CR and LF (0x0D,
0x0A). This is also the way that IETF protocols denote line ends.

* One character that does both things. People have used each of CR and LF
to do this, so this is two mechanisms under one bullet.

* Line ends are meta-data. Record-oriented (as opposed to stream-oriented)
systems do this. For example, imagine storing a file as a stream of counted
strings, each one denoting a line. There's no actual line end in this file,
they're inferred by the sizes of each line.

It really doesn't matter how you denote any of this stuff (not even
character set) until you want to move a chunk of data from one system to
another and preserve its semantic content. There are a couple of ways to do
this:

* Declare an interchange format, and always translate your chunk into this
format when you transmit it, and out of it when you receive it.

* When you transmit your chunk, tell your partner what format it's in, and
let them translate it.

It is my belief that in OpenPGP, we do the former -- we have an interchange
format for text. That format consists of the ISO 10646 character set that
has been encoded into UTF-8. Additionally, we use CRLF line-ends, and
perhaps controversially, trim trailing white space from the end of each
line. Note that there is at least one more semantic ambiguity in this
interchange format -- tabs. Let's not go there right now, but arguably, we
should do something about that, too.

It is also my belief that when a chunk of data is marked as being "text"
that it is an assurance that the chunk of data has been translated into
that interchange format. This is what we mean by "text canonicalization."

An interesting side-effect of this is that when I verify a signature over a
chunk of data, it doesn't matter whether it's "text" or "binary." You can
just hash the chunk, compute the signature, and poof, you're done. Also,
interestingly, it means that minor errors in canonicalization (let's
suppose that someone's canonicalizer occasionally leaves in a trailing
space, or it sometimes encodes two blank lines as CR, LF, LF -- I've seen
both these errors over the years) don't affect signature checks.

Text mode, as we call it, should only come into play when you display text,
or want to use that chunk as text (like writing it out into a file). If you
verify a signature over a text file (call it foo.c), and then want to write
it out on a unix system, you need to translate the CRLFs into LFs. You have
to deal with what it means to have a bare CR, what to do about the
character set (your user might be using Shift-JIS or Big5), and you'll have
to massage that chunk to preserve its semantic content.

I believe that when a blob is marked as text mode, it's an *assurance* that
you've transformed the blob into "text mode." It is *not* an advisory to
tell your partner that every time they see a bare LF they should drop an
extra CR into the hash. Should such an implementation exist, I believe it
is wrong. Text mode means you have translated the blob from your local
format into the interchange format and its binary content is that of the
interchange format.

The IETF meta-rule we keep coming back to is to be conservative in what you
generate, and liberal in what you accept. So -- you should only mark a
chunk of data as "text" if it's been run through a canonicalizer that
transforms it into our interchange format. On the other hand it is
reasonable, but not necessary, that you accept something that's not
strictly right. For example, let's suppose that an OpenPGP implementation
has a bug in it and that bug is that after the canonicalizer has been run,
the message is generated with the pre-canonicalized text. Oops. What we
have in this is unix text (LF line-ends, let's say and ignore the character
set issues), but a signature that was computed over the same text with CRLF
line ends. If an implementation were, after failing to verify the signature
on the blob, to use a heuristic that tried to compensate for that encoding
error then I think we'd all applaud. That software would say to itself,
"Hmm, this signature didn't check. Let me look at the file. Well, well.
It's got 37 LFs and not a single CR. I'll bet that someone made a mistake.
Let's add in those CRs and check the signature again. Hey, look at that, it
works."

But that's mostly a digression. The point I'm making is this: Whatever
problems text mode, canonicalization, and translations give you, there
should be zero problems in signature checking. A signature is a signature
is a signature is a signature. The signature should be over the actual data
as found in the data packet.

While I'm at it, I'll mention that as far as OpenPGP is concerned, there
are other things a canonicalizer can do. It can, for example, translate
tabs into spaces. Heck, it can translate ANSI escape sequences into HTML,
or HTML into RTF, for all OpenPGP cares. The end users may care, but it's
OpenPGP compliant. You can always do more than what the standard says. Your
users might not like it, but the standard doesn't care.

	Jon

---

From: David Shaw <[email-masked]>
Date: Thu, 27 Dec 2001 19:33:37 -0500

This sounds very good, but what about detached signatures?  A detached
signature doesn't carry the text with it, so wouldn't the the text
(presumably delivered via http or ftp, which can change line endings)
need to be re-canonicalized for signature verification?  To a certain
degree this applies to a clearsigned document as well.

Email delivery of the text is a whole other can of worms, though it
could be argued that if it's email, it should be PGP/MIME.  Even so,
canonical text should be able to handle the most common sorts of email
butchery without PGP/MIME.

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

---

From: "vedaal" <[email-masked]>
Date: Fri, 28 Dec 2001 08:15:07 -0500

----- Original Message -----
From: "David Shaw" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 27, 2001 7:33 PM
Subject: Re: Text canonicalization

...
> degree this applies to a clearsigned document as well.
...
also applies somewhat to GnuPG signed and encrypted messages when signed
with a v3 rsa key, and GnuPG armored signed messages with a v3 rsa key,
PGP interprets it as a 'detached' signature,
and 'searches' (unsuccessfully) for the file trying to verify it.
{not the case with v4 rsa sigs, which seem to act differently}

vedaal

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: Text canonicalization
Date: Fri, 28 Dec 2001 08:15:07 -0500
Sender: [email-masked]

----- Original Message -----
From: "David Shaw" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 27, 2001 7:33 PM
Subject: Re: Text canonicalization

...
> degree this applies to a clearsigned document as well.
...
also applies somewhat to GnuPG signed and encrypted messages when signed
with a v3 rsa key, and GnuPG armored signed messages with a v3 rsa key,
PGP interprets it as a 'detached' signature,
and 'searches' (unsuccessfully) for the file trying to verify it.
{not the case with v4 rsa sigs, which seem to act differently}

vedaal

Date: Thu, 27 Dec 2001 19:33:37 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Text canonicalization
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Date: Thu, 27 Dec 2001 16:17:14 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Text canonicalization
Sender: [email-masked]

That's a good discussion, but it doesn't cover the case of a detached
signature on a text document.  In that case the document is not subject
to OpenPGP text canonicalization on signature creation, and hence cannot
be assumed to have been canonicalized on signature verification.

We could just rule this case out.  I think that's what Jon's analysis
would suggest.  If you can't canonicalize it, you can't call it text.

However there may be some people who would like to use this feature.
They want to sign a text document which they are distributing, but they
want to put the signature in a separate file.  That way the text document
is accessible to everyone without being cluttered with crypto crud.

The problem with this case is that text documents tend to get transported
in two ways, using such transports as FTP.  One way converts the document
to the native text format of the recipient machine, generally just
converting line endings.  The other way preserves the document unchanged.

Ideally, we could adopt conventions which would allow most of these
cases to work correctly.  We won't be able to handle every variant and
every machine's notion of text, because there are so many obscure ones
out there.  But we could capture the great majority of cases with some
simple rules.

These rules are that the document should be canonicalized with all of
CRLF, CR and LF being treated as line endings, and being turned into
CRLF for hash purposes.  This was what I proposed.  I continue to believe
that this simple rule provides the maximum flexibility to the end user.

Hal Finney

Date: Thu, 27 Dec 2001 14:00:41 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Text canonicalization
Sender: [email-masked]

	Jon

Subject: OpenPGP Toolkits Available?
To: [email-masked]
From: [email-masked]
Date: Mon, 17 Dec 2001 10:39:03 -0600
Sender: [email-masked]

From: John Dlugosz

What OpenPGP toolkits are available?  I'm specifically looking for
something that doesn't have licencing fees.  I've found CTClib which has
not been updated since 1997, and a new suite in Perl.  I'd like to find
some free source code in C or C++.

--John

To: [email-masked]
Subject: Re: text + openpgp  !=  mime
From: Florian Weimer <[email-masked]>
Date: 17 Dec 2001 11:42:40 +0100
Lines: 13
Sender: [email-masked]

John Kane <[email-masked]> writes:

> There seems to be a strong tendency to automatically misinterpret
> any reference to 'text', newlines, or cross-platform issues as
> somehow being inherently MIME-related.

In the RFC 2440 context, 'text' is defined to be encoded in UTF-8.
Perhaps this isn't what you want, either.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: text + openpgp  !=  mime
Date: Mon, 17 Dec 2001 09:57:44 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 12
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Mon, 17 Dec 2001 09:57:44 +0000 (UTC)
Sender: [email-masked]

* John Kane wrote:
>Am I correct in assuming that there are valid, legitimate uses for
>standalone OpenPGP implementations which are NOT integrated into a
>mailreader?

Yes.

>What keywords should people use if they want to indicate that they want to
>discuss an issue within a pure RFC2440 context, or within a context of
>addressing legacy-PGP / OpenPGP interop nits?

Binary.

Date: Sun, 16 Dec 2001 15:55:24 -0500
From: John Kane <[email-masked]>
To: IETF-OpenPGP <[email-masked]>
Subject: text + openpgp  !=  mime
Sender: [email-masked]

Some readers of this list, those who are engaged in the noble
task of implementing PGP/MIME, seem to have fallen into an
email-centric rut and appear to have great difficulty grasping
the concept of using RFC2440 in a non-email, non-MIME, non-MUA
environment.

Am I correct in assuming that there are valid, legitimate uses
for standalone OpenPGP implementations which are NOT integrated
into a mailreader?  Am I also correct in assuming that this list
is an appropriate forum for discussing issues relating to plain
vanilla RFC2440(bis)?

There seems to be a strong tendency to automatically misinterpret
any reference to 'text', newlines, or cross-platform issues as
somehow being inherently MIME-related.  What keywords should
people use if they want to indicate that they want to discuss
an issue within a pure RFC2440 context, or within a context of
addressing legacy-PGP / OpenPGP interop nits?

Pardon my blunt language, but this needs to get resolved.
Several recent RFC2440 threads have been cut short by posters
who change the subject to a non-RFC2440 context.  :-(

-- 
John Kane
New Hampshire (USA)

Date: Fri, 7 Dec 2001 18:08:06 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Notation data language
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

>>I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens)
>>to create PGP signatures.
>
>encoded according to rfc2253?

Encoded according to DER.  This is for finding a cert, not for human use (for 
one thing half the issuerAndSerialNumbers around wouldn't survive a DER ->
text -> DER conversion).

Peter.

To: [email-masked]
Subject: Re: Text canonicalization
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 06 Dec 2001 18:37:06 +0100
Lines: 30
Sender: [email-masked]

  Werner

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Notation data language
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 06 Dec 2001 18:24:54 +0100
Lines: 13
Sender: [email-masked]

On Thu, 6 Dec 2001 12:58:37 +1300 (NZDT), Peter Gutmann said:

> I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens)
> to create PGP signatures.

encoded according to rfc2253?

Does it make sense to encode the name like "oid.1.3.6.1.4.1.11591" so
that we have a defined namespace for such extensions?  There is also
Thomas Roessler's proposal based on DNS domains but for X.509 stuff
OIDs are the more natural approach.

  Werner

Date: Wed, 5 Dec 2001 19:20:05 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Notation data language
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Dec 05, 2001 at 03:58:08PM -0800, [email-masked] wrote:
> David Shaw writes:
> > As I see it (and this departs from the language in the draft), being
> > human readable shouldn't necessarily mean that the data cannot also be
> > machine readable.
> >
> > To use the URL example, if there was a "[email-masked]" name
> > (to use the proper user name space from the draft), and that was
> > defined as a URL for my home page, I don't see any particular reason
> > why a machine shouldn't process such data - the processing function
> > would be keyed off of the "name" value, so the program would have a
> > pretty good notion of what was going to be present in the "value"
> > field.
> 
> Instead, I would handle this by not setting the human-readable flag, and
> instead choose a name for the notation which tells the machine that it
> is a URL.  Then the software can know that URLs can be safely displayed
> to a human.  Leaving the human-readable flag clear allows the software
> to read and try to understand the notation.  Nothing prevents it from
> displaying it to a human if the semantics of that notation imply that
> it would be reasonable.

Yes, that would work as well.  Still, I think that allowing the
implementation to look at human-readable notations is more flexible in
that a new notation tag can be at least partially supported without
code changes.

If human-readable meant printf()-able, then the code could just
display anything that had the human-readable flag set so at least the
user could see the notation and thus have partial support for the new
tag.  The software implementation could not handle the notation
without a upgrade, but I suspect that while automation is nice, many
notations could be handled by a user as well (for example: "This key
is revoked, please use key 0xXXXXXXXXXX instead").

David

Date: Wed, 5 Dec 2001 15:58:08 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Notation data language
Cc: [email-masked], [email-masked]
Sender: [email-masked]

David Shaw writes:
> As I see it (and this departs from the language in the draft), being
> human readable shouldn't necessarily mean that the data cannot also be
> machine readable.
>
> To use the URL example, if there was a "[email-masked]" name
> (to use the proper user name space from the draft), and that was
> defined as a URL for my home page, I don't see any particular reason
> why a machine shouldn't process such data - the processing function
> would be keyed off of the "name" value, so the program would have a
> pretty good notion of what was going to be present in the "value"
> field.

Instead, I would handle this by not setting the human-readable flag, and
instead choose a name for the notation which tells the machine that it
is a URL.  Then the software can know that URLs can be safely displayed
to a human.  Leaving the human-readable flag clear allows the software
to read and try to understand the notation.  Nothing prevents it from
displaying it to a human if the semantics of that notation imply that
it would be reasonable.

Hal

Date: Thu, 6 Dec 2001 12:58:37 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Notation data language
Cc: [email-masked]
Sender: [email-masked]

David Shaw <[email-masked]> writes:

>For what it's worth, although none have been officially described by the IETF,
>some notations are being used.  On my keyring at the moment exist a few
>notations names like "Certification" and "COMMENT" (and a handful of "foo", of
>course).

I'm using "issuerAndSerialNumber" to allow X.509 keys (eg in PKCS #11 tokens)
to create PGP signatures.

Peter.

Date: Wed, 5 Dec 2001 18:54:07 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Notation data language
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Dec 05, 2001 at 03:14:29PM -0800, [email-masked] wrote:
> Here is the draft language:
> 
>    All undefined flags MUST be zero. Defined flags are:
> 
>        First octet: 0x80 = human-readable. This note is text, a note
>                            from one person to another, and has no
>                            meaning to software.
> 
> My interpretation is that this is not so much a guarantee that the data
> is human readable, as that it is NOT machine readable.  In other words
> the operational effect is that software should not try to interpret it.
> It would be OK to have it be in some secret language that only one other
> person could understand.  So on this basis if you wanted to put a URL
> in there that would be fine, setting this flag just says that software
> shouldn't try to parse and understand it.

Hmm.  I read this to say that the data was human readable in that it
could be shown to a human being without special processing (i.e. that
it was printable, and not a chunk of binary data).

As I see it (and this departs from the language in the draft), being
human readable shouldn't necessarily mean that the data cannot also be
machine readable.

To use the URL example, if there was a "[email-masked]" name
(to use the proper user name space from the draft), and that was
defined as a URL for my home page, I don't see any particular reason
why a machine shouldn't process such data - the processing function
would be keyed off of the "name" value, so the program would have a
pretty good notion of what was going to be present in the "value"
field.

David

Date: Wed, 5 Dec 2001 18:53:56 -0500
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Notation data language
Mail-Followup-To: Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Dec 05, 2001 at 02:26:18PM -0800, Jon Callas wrote:
> You are right, the human-readable flag applies to the data, not the name.
> I'll add in what you wanted, to make it clearer.
> 
> As for the name -- well, I have no idea.
> 
> I have an intuitive sense of what human readable means for the value. For
> example, "I have read this document, but do not agree with much of its
> content, call or email for long-winded details" is a fine human-readable
> notation, and one of the purposes it's there for. I can even understand
> that the semantic content of that note can be put in any arbitrary language
> and encoded in whatever alphabets in unicode, and it's still "human
> readable" even if that human better speak Esperanto.

I'm not currently generating notations - the question arose from an
implementation choice on whether to print all names even if I could
not print all values.  If I was generating notations, I'd use the
2440bis method - it provides the happy accident of looking like an
email address so you can be contacted by someone who wants to add
support for the private tag to their implementation.

When I read the draft, I assumed human-readable meant that the data
was able to be shown to a human being without special processing.
Something close to "if I can printf() it, it's human readable" (of
course there is UTF8, but I think you get my drift).

David

Date: Wed, 5 Dec 2001 15:14:29 -0800
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Notation data language
Sender: [email-masked]

Here is the draft language:

   All undefined flags MUST be zero. Defined flags are:

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

My interpretation is that this is not so much a guarantee that the data
is human readable, as that it is NOT machine readable.  In other words
the operational effect is that software should not try to interpret it.
It would be OK to have it be in some secret language that only one other
person could understand.  So on this basis if you wanted to put a URL
in there that would be fine, setting this flag just says that software
shouldn't try to parse and understand it.

Hal

Date: Wed, 5 Dec 2001 14:26:18 -0800
To: David Shaw <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Notation data language
Sender: [email-masked]

You are right, the human-readable flag applies to the data, not the name.
I'll add in what you wanted, to make it clearer.

As for the name -- well, I have no idea.

I have an intuitive sense of what human readable means for the value. For
example, "I have read this document, but do not agree with much of its
content, call or email for long-winded details" is a fine human-readable
notation, and one of the purposes it's there for. I can even understand
that the semantic content of that note can be put in any arbitrary language
and encoded in whatever alphabets in unicode, and it's still "human
readable" even if that human better speak Esperanto.

But is "method://whatever/goes/in/a/uri" human-readable? Tim Berners-Lee
thinks not. Or thought not. The protocol we describe in 2440bis for names
doesn't make them human readable in some sense of the word, and in fact
clucks its tongue at a name like "Statement about what my signature means"
which is a *fine* human readable name to go along with the human readable
value.

My opinion is this: Pick your names with a small amount of wisdom. No
matter what you do, someone will be sure to tell you that you did the wrong
thing. A notation means what its creator wants it to mean. Unlike most
data, since this is contained in a signature, there's a known creator of
that data. Consequently,  the disambiguation we have in the standard is
really overkill. However, the reason for a notation is communication, and
there are two parties in communication. If you pick a name tag that someone
else will interpret differently than what you mean, then you have a
problem. That's why a small amount of wisdom is needed, and if you pick
some scheme like the one in 2440bis, or the backwards-domain scheme that
Java uses, fewer people will cluck their tongues at you than would if you
used a name like "a". And yet a name like "ReadMe" is pretty obvious, even
if squishy and non-standard. You're a bright guy, there are lots of
reasonable things to do. Pick one.

	Jon

Date: Wed, 5 Dec 2001 10:44:46 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Notation data language
Cc: [email-masked]
Sender: [email-masked]

Maybe the best thing would be if you could tell us more about how you
are planning to use notation data.  This is not a feature which is
currently used in PGP, it is intended for support of new applications.
It's always difficult to specify a feature when you don't know how it
will be used.  Usually in IETF we try to do things the other way around.
But this was intended as an escape clause for future expansion, so we
had to specify it without any practical experience to guide us.

Hal

To: [email-masked]
Subject: Re: Text canonicalization
From: Florian Weimer <[email-masked]>
Date: 05 Dec 2001 21:07:29 +0100
Lines: 17
Sender: [email-masked]

Date: Wed, 5 Dec 2001 14:26:21 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Notation data language
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Dec 05, 2001 at 10:44:46AM -0800, [email-masked] wrote:
> Maybe the best thing would be if you could tell us more about how you
> are planning to use notation data.  This is not a feature which is
> currently used in PGP, it is intended for support of new applications.
> It's always difficult to specify a feature when you don't know how it
> will be used.  Usually in IETF we try to do things the other way around.
> But this was intended as an escape clause for future expansion, so we
> had to specify it without any practical experience to guide us.

Understood.  Unfortunately, I'm not sure we're really communicating.
I'm not creating any notations.  However, I am writing code that can
display notations.

The question can be boiled down to whether the "name" of the
name=value pair is always human readable.  "Human readable", to me,
meaning that it is made up of characters that can be displayed in some
more or less readable way (i.e. printable characters).  As I said, the
draft seems to say that this is the case.  If it isn't the case,
that's fine too.  I'm just trying to clarify the point.

For what it's worth, although none have been officially described by
the IETF, some notations are being used.  On my keyring at the moment
exist a few notations names like "Certification" and "COMMENT" (and a
handful of "foo", of course).

David

Date: Wed, 5 Dec 2001 09:59:15 -0800
From: [email-masked]
To: [email-masked]
Subject: Text canonicalization
Sender: [email-masked]

Comments?

Hal Finney
Network Associates

Date: Wed, 5 Dec 2001 13:37:40 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Notation data language
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Dec 05, 2001 at 10:18:24AM -0800, [email-masked] wrote:
> David Shaw writes:
> > I've been writing some code involving notation data (5.3.2.16 in
> > bis-03).  As I read it, the human-readable flag applies to the value
> > data of the name=value pair and not to the name data.
> >
> > If I do read this correctly, I'd like to suggest a change in the line
> > "This note is text, a note from one person to another, and has no
> > meaning to software." to read "The value is text, a note from one
> > person...", etc, which would help make clear what the human readable
> > flag applies to.
> 
> I don't fully understand the distinction.  You are saying that the
> "name" part would be machine readable, but the "value" part would not?

Other way around - the language in the draft ("Notation names are
arbitrary strings encoded in UTF-8") strongly suggests that the the
human-readable flag only applies to the "value", and the "name" is
always human readable, albeit UTF8.

I was hoping to make the language clearer, or if I misread the
document, to make it clearer in the other direction :)

David

Date: Wed, 5 Dec 2001 10:18:24 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Notation data language
Sender: [email-masked]

David Shaw writes:
> I've been writing some code involving notation data (5.3.2.16 in
> bis-03).  As I read it, the human-readable flag applies to the value
> data of the name=value pair and not to the name data.
>
> If I do read this correctly, I'd like to suggest a change in the line
> "This note is text, a note from one person to another, and has no
> meaning to software." to read "The value is text, a note from one
> person...", etc, which would help make clear what the human readable
> flag applies to.

I don't fully understand the distinction.  You are saying that the
"name" part would be machine readable, but the "value" part would not?
What would be the point of trying to restrict the name to be machine
readable if it couldn't do anything with the value?  I think it makes
more sense to say that this flag means that machines shouldn't try to
read any of the notation, rather than that they can read part of it but
not the rest.

Hal Finney

Date: Tue, 4 Dec 2001 17:51:50 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Notation data language
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I've been writing some code involving notation data (5.3.2.16 in
bis-03).  As I read it, the human-readable flag applies to the value
data of the name=value pair and not to the name data.

If I do read this correctly, I'd like to suggest a change in the line
"This note is text, a note from one person to another, and has no
meaning to software." to read "The value is text, a note from one
person...", etc, which would help make clear what the human readable
flag applies to.

David

From: Marc Mutz <[email-masked]>
Organization: KDE
To: John J Kane <[email-masked]>, [email-masked]
Subject: Re: prefer "- From " instead of ">From "??
Date: Sun, 2 Dec 2001 20:59:17 +0100
Sender: [email-masked]

On Thursday 29 November 2001 14:32, John J Kane wrote:
<snip stuff "^From " with "- ">
> This may be the sanest way to handle that case.
> Comments?

For an OpenPGP implementation this is OK, I guess. But the real fix is 
replacing one of the five chars "From " with it's quoted-printable 
hexchar, e.g. "From=20". This kills all issues at the most appropriate 
level: The MUA.

But this only works for messages encoded in qp, though I wouldn't 
hesitate forcing the MUA to use qp for text that matches "^From ", 
KMail/Aegypten in our case.

Marc

- -- 
FTAA's anti-circumvention provisions represent US imperialism at its
worst. They seek to impose restrictive laws on both the US and other
countries, in order to prevent established US businesses from facing
both domestic and foreign competition.
              -- EFF FTAA Alert:
                 Stop Hollywood Forcing Technology Ban on 34 Countries