Subject: Re: Some -15 comments

From: Ian G <[email-masked]>
Date: Thu, 01 Dec 2005 10:39:43 +0000

David Shaw wrote:
> On Wed, Nov 16, 2005 at 03:07:20AM +0100, Daniel A. Nagy wrote:
> 
> 
>>As for the subject of our discussion, I think that we all agree that the
>>spec for 0x80 should be stripped of "a note from one person to another..."
>>bit., because one major implementation does not treat it that way.

Yes.

>>The only disagreement seems to be whether "a note from one person to
>>another" should be retained as an interoperable feature or should it be
>>delegated to private notation namespace.
>>
>>The disadvantage of the  latter approach would be that various implementers
>>would (possibly) implement this same semantics with a host of different
>>notation names and won't interoperate.
>>
>>Now, I can see that implementing the former using a type flag also causes
>>problems. Maybe, it should be a common, ITEF-namespace notation? Or an
>>entirely separate subpacket type akin to "reason for revocation"?

My view - it has to be outside the spec.  "a note
from one person to another" is a very high level
thing and we'll never be able to nail down what
it means.  And if we do, we then have to add all
the other variants like "a note from one person
to two persons..." "a note from the program to a
person..." "a note in XML..."

>>I am not sure. But in either case, as far as immediate modifications to the
>>standard text are concerned, this "a note..." part should be removed from
>>the definition of 0x80, because it means something that 0x80 definitely
>>doesn't. Whether or not to add that text someplace else is  an entirely
>>different question.
> 
> 
> Is this rough consensus?

Removing that part, yes, I would agree.

iang

PS: point of order here - as we are in last
call, what are we "permitted" to change?  Only
completely wrong things?  Or is this flexible?

iang

---

From: Jon Callas <[email-masked]>
Date: Wed, 28 Dec 2005 14:25:04 -0800

On 15 Nov 2005, at 6:07 PM, Daniel A. Nagy wrote:

>
> On Tue, Nov 15, 2005 at 10:16:57AM -0800, "Hal Finney" wrote:
>
>> example imagine a signature which says, I am not vouching for the  
>> binding
>> between userid and key, but rather I am making a certain assertion  
>> about
>> this userid or key.  If we don't understand this notation the correct
>> thing is to ignore the signature, and that is in fact what the  
>> spec says
>> should happen.
>
> Yes, that is my understanding as well. Critical notation means that  
> it is
> essential for the correct interpretation of the signature and without
> understanding the notation the signature is meaningless.
>
>> Critical notations allow implementors to essentially extend signature
>> semantics beyond the official set of signature types.  We have a  
>> protected
>> namespace for proprietary extensions, and we have the ability for  
>> legacy
>> applications silently to ignore unrecognized extensions.  It's a good
>> feature.
>
> I agree.
>

In cleaning things up, I think I should say that despite discussions,  
I don't see anything in what Daniel, Ian, or Hal have said that I  
disagree with, and think we're in violent agreement.

	Jon