To be done list for editing

Just so folk know where I am here is the list of edits that I have not yet
completed:
In addition I need to fix some code.
 
 
303 Denis Pinkas: 8. 

The two overviews from sections 1.5 and 1.6 do not provide a clear 
picture of the functions that are supported. They should be both revised.> A

text is proposed as an annex at the end of these comments.

Resolution - Editorial - some text to be merged

 

303 Denis Pinkas: 20. 

The text under [177] mentions the <UseKeyWith> element which specifie>s a 
subject identifier and application identifier that determine a use of the> 
key. The <UseKeyWith> must contain "Application" which is a URI that 
specifies the application protocol with which the key may be used and 
"Identifier" which specifies the subject to which the key corresponds
wit>hin 
the specified application protocol. A protocol can support a sender and a> 
receiver. It is unclear whether the Identifier corresponds to the sender >or

the receiver. It seems that the notion is by itself insufficient and shou>ld

be extended to make such difference.

Noted, the issue is not one of 'sender' and receiver but instead 'self' and
'other'. It is possible to imagine that a client might have need to ask
which key it should itself use for a particular protocol.

 

304 Carlisle Adams: 4

Section 6.1.1: Example: Registration of Client-Generated Key Pair. In the
element, there is no key identifier. How is the service supposed to know
which key to use to verify this binding? Is it supposed to be implied from
the elements in ? If so (or if there's some other way that the service is
supposed to figure this out), shouldn't this be specified somewhere so that
implementers know what to build? 

305 Joseph Reagle

Document doesn't flow as smoothly as it might: 

1.	Section 1 says there are two "service specifications" but doesn't
say where they are more fully described or specified. Forward references? 

2.	The sections in section 1.7 do not correspond to the sections of the
table of contents. 

3.	Section 1.5 has the same title as Section 4 (except that it has
"specification"). How to make this flow better, or at least use the term (r
not) "specification" consistently. 

4.	Generally, I don't distinguish between a "message format" and a
"message syntax." What do these section do differently?