[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] Groups - wd-xri-specification-01.doc uploaded
|
I think security and privacy should be called out as a separate section. It’s required in any RFC and good practice elsewhere, even if it’s just to say that no security considerations exists. At the very minimum we need to think about how security considerations in XRIs relate to section 7 of 2396.
-----Original Message-----
Drummond- [All references in this list are to the numbering in the document you sent out] 1) We'd want to reorg this into a 3 part document: Introduction, Syntax, and Resolution (which includes security issues related to resolution). We don't think there is a security section for syntax-related issues.
2) Sections 2.1 and 2.2 should after section 3 (syntax components) in the Syntax part. While this breaks the parallelism to RFC 2396, we think its more natural reading.
3) Section 2.3 should become its own section (in the Syntax part), before the section on Normalization and Comparison
4) Relative XRIs - we still have substantive questions about this - RFC 2396 only talks about syntactic relativity - is that what we are talking about here? Also how is a relative XRI (in the rfc 2396 sense) disambiguated syntactically from the relative forms in the sense that we mean "relative" for XRIs.
5) Under Normalization and Comparison, there is no discussion of Normalization. But, we think there probably DOES need to be a discsion of normalization before talkin about equivalence and comparison (at the very least to address normalization of I18N XRIs)
6) Section 5.2 - "Indirect equivalence". We think that once you get beyond syntactic definitions of equivalence, you open up a whole pandora's box of issues and that one could argue any equivalence is applicaiton -specific (and that you start needing to define equivalence in different ways). This doesn't seem appropriate for this document. Maybe a sentence or two suggesting that there are other ways of describing equivalence (e.g. two XRIs resolve to the same "persistent" XRI), but this shouldn't be normative in this document, and I think getting it precise enough is going to turn out to be a rat hole of effort (at least in the general case).
7) In the security section, we think that everything mentioned here (except for security w/r/t resolution ) sounds non-normative and shouldn't be part of the specification. Perhaps in the non-normative document..
8) Why is section 4.2 named the same as section 4?
9) For sections 4.1 (Relative URIs) and section 5.1 (URI Equivalence), these don't seem like they should be separate sections, but maybe just introductory text, since they aren't defintional.
10) What 5.3.1 and 5.3.2 - what is special about resolvability in the case of cross reference that needs to be called out in the equivalence section?
11) We'd put references as appendix A instead of section 8.
12) The examples on page 1 can't be so "naked" and need more explanation (just amplifying this again ;-)
So, here is our proposed outline:
1. Introduction everything from old section 1 here
2. Syntax 2.1 Syntax Components 2.1.1 Scheme 2.1.2 Authority 2.1.3 Path 2.1.4 Query 2.1.5 Fragment 2.2 Character Encoding 2.3 Escaping 2.4 Relative XRIs 2.4.1 Relative XRIs 2.4.2 Usage of Relative XRIs 2.5 Internationalization 2.6 Normalization and Comparison 2.6.1 Normalization 2.6.2 XRI Equivalence 2.6.2.1 Cross-Reference Equivalence 3. Resolution this section is probably going to get changed completely, so no comment now 3.x Security Considerations Appendix A. Normative References Appendix B. Informative References Appendix C. Collected ABNF for XRI Appendix D. Acknowledgements Appendix E. Revision History Appendix F. Notices
-Mike and Gabe
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]