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-----
From: Wachob, Gabe
[mailto:]
Sent: Wednesday, June 25, 2003
12:12 PM
To: 'Drummond Reed';
Subject: RE: [xri-editors] Groups
- wd-xri-specification-01.doc uploaded
Drummond-
We have some feedback:
[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
> -----Original
Message-----
> From: Drummond Reed [mailto:]
> Sent: Tuesday, June 24, 2003 8:34 PM
> To:
> Subject: RE: [xri-editors] Groups -
> wd-xri-specification-01.doc uploaded
>
>
> Guys,
>
> We're rolling! The posted doc is the first draft of the real
> thing from
> DaveM and I based on the outline we discussed last week. It's
> been moved
> into the official OASIS template; all proposed section headings have
> been added to the outline; and Section 1 has been filled in completely
> with a first draft.
>
> I'm going to be cranking all day tomorrow on sections 2 and 3 with the
> goal of having a first draft of both (or close) by COB tomorrow. I'll
> post whatever I have by that point.
>
> The goal in posting this tonight was to give all editors a
> look at what
> it looks like and start to get initial feedback about the structure,
> tone, and general style. Please do post any general or
> specific comments
> and/or propose issues to be discussed on Thursday's call.
>
> Gabe, Peter: the Resolution section is just a SWAG at what heading
> you're going to want there, so that section can be replaced wholesale
> with the way you plan to organize it.
>
> Thanks,
>
> =Drummond
>
> -----Original Message-----
> From: Drummond Reed
> Sent: Tuesday, June 24, 2003 8:19 PM
> To:
> Subject: [xri-editors] Groups - wd-xri-specification-01.doc uploaded
>
> The document wd-xri-specification-01.doc has been submitted
> by Drummond
> Reed () to the XRI Editors SC document
> repository.
>
> Document Description:
> 01 draft for review of structure and Section 1 by Editor's TC.
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/xri-editors/downl
oad.php/26
60/wd-xri-specification-01.doc
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/xri-editors/document.php?do
cument_id=2660
PLEASE NOTE: If the above links do not work for you, your email
application
may be breaking the link into two pieces. You may be able to copy and
paste
the entire link address into the address field of your web browser.
-OASIS Open Administration
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
