--- Begin Message ---
Here are a few comments (most are minor) on
draft-ietf-sacred-protocol-beep-pdm-00
5.1 Mismatched XML start and end tags
<SacredDownloadQuery>
</SacredQuery>
and
<SacredDownloadResponse>
</SacredResult>
Section 6.2 quotes around application/beep+xml are wrong (this indicates
that Marshall's excellent 2629 utility is not being used)
[AES] is in references, but not referred to in the text (should be in
section 5.2, number list, 5)
Not much discussion of transport security /SASL authentication in BEEP -
this might be intentional - (i.e. enough is said in sections 3 and 4 of RFC
3080) but I would not be surprised if someone has something extra to say in
SACRED
Section 1. "saving as much computation as possible for the server"
This can be read in two ways - I know you want to say that the client does
the work, but it could also be read as you are trying to save as much work
from the client and place the burden of the computation onto the server
(think that many coming to this spec will always assume that it is good to
move the computing burden off the client). Maybe using a word such as
"minimizing" rather than "saving".
Section 5.7 its not clear --> it's not clear
Section 2.3 How to handle proxying functionality - Use Darren New's TUNNEL
for BEEP?
5.7 Error codes in BEEP
Is it really neccessary to copy all this from RFC 3080 - could you not just
reference it
5.7 quotes around "error" are off
6. "Author's Addresses" has a funny character in it
Appendix B: Is the first line right?
Is the schema or the DTD (Appendix B) the one to use in case of conflict?
======
That's it. In general, it looks good and seems pretty clear how one would go
about implementating it.
Eamon
--- End Message ---