RE: [xri] Comments on draft-resolution-04

["Sakimura, Nat" <n-sakimura@nri.co.jp>]

Haven't finished reading it, but just a couple of points: May overlap
with other's comment 
since I have not checked them yet, but...

Since line number seem to depends on the paper size, I am not using it.
Instead I try to 
refer by section number etc. (We really should be using Wiki for this...
or text base document 
with line breaks so that we can use diff and patch.) 

Table 4: The header shows xri://@:a:b -> xri://@!a!b , I guess. 

Section 2.3 
  "HTTP URL" -> "HTTP URI", I guess

Section 2.3  Exabit of HTTPresponse: 
  At XRIDescriptors/XRIDescriptor/Synonyms/External: 
  It states xri://@example2/path 
  At a glance, it seems it contradicts to the statement about local 
   access in Section 2.2.8. If this is right, some explanation is in
order. 

Section 2.4.2 Frist line. 
  ... section 4.3 or [RFC2483] -> ection 4.3 of [RFC2483] 

[GENERAL]
I am a fresh-eye for this thing as I have not been involed in the
process. (I regret.) 
However, this means I am uniquely positioned to experience what the 
other people would feel when first exposed to this document. 

Here are bullet points: (Sorry, I have no time now. I would expand them
later. )

- BULKY
- Looks more like a white paper than a spec. 
- Useful to have UML Sequence Diagram for the description of the 
  resolution process. 
- One could condense the normative spec to perhaps only 10 pages. 
  Better separate the bulky explanation (I found it extremely useful,
though) 
  and the main spec. 
- Figure 2 hard to understand

Well, time up... to be continued...
 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Tuesday, March 01, 2005 7:46 AM
> To: 'Wachob, Gabe'; xri@lists.oasis-open.org
> Subject: RE: [xri] Comments on draft-resolution-04
> 
> Gabe,
> 
> Some of my comments overlap with Peter's, plus I have 
> boatloads of regular text editing comments (per the partially 
> review draft I sent you this morning). I am 1/2 way through 
> Trusted Res. and will send you my completed draft as soon as 
> I am finished with it (current ETA ~6pm tonight).
> 
> =Drummond  
> 
> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Monday, February 28, 2005 1:27 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Comments on draft-resolution-04
> 
> page 6 : figure 1 it might be more clear to also show what 
> gets returns in this diagram (assuming space allows)
> 
> page 29 line 224: it is also possible to have @a*b*c be both 
> an authority (over *d) and a local access point is it not? if 
> so, then i think this should be noted (actually, i  think it 
> is the common case)
> 
> line 286 & 289: "MUST no longer be relied upon" i think 
> should be phrased "MUST NOT be relied upon" (preferring the 
> normative negative form)
> 
> line 692: references "!" as a GCS Char for annotations, which 
> it is no longer
> 
> Table 4 line 698: ":" in col heading should be "!"
> 
> line 1025: for 'reasonable' caching, whatever that means, it 
> is unlikely that authorities can/should be aware of 
> down-stream cache duration directives, thus i think the 
> advice concerning the cache relative to the resolution chain 
> should be dropped, and we should simply point out that cache 
> times may vary, and the resolver should simply adhere to the 
> 'shortest-lived' cache for the resolution sequence.
> 
> section 2.7 general: nothing is said about caching 
> computations for lookahead resolution... that is, the 
> XRIDescriptors/XRIDescriptor elements each may contain 
> different caching.  I think some explanatory text such as 
> "When look-ahed or proxied resolution is used, the resolving 
> client MUST expire the entire XRID when the first expriration 
> of a node in the resolution chain described in the XRID is reached." 
> In addition, i think some advice on how lookahead and proxies 
> compute the value for the HTTP Expires header for their 
> response back to the client, based on the cummulative 
> expirations set buy both the HTTP headers and Expires 
> elements in the chain of resolution steps they perform on 
> behalf of the client.
> 
> line 1075: might i suggest that since there may be other 
> trusted resolution proposals in the future, that we enrich 
> the mediatype for the resolution request (Accept header) to 
> xdrd-t-saml+xml or something.
> 
> line 1114: rather than explaining that =example and 
> example.org similarities are coincidental, why don;'t we just 
> make them different strings ;-)
> 
> line 1483: fix reference to resolution section (2)
> 
> line 1606: +1 on gabes note on requiring KeyInfo.
> 
> line 1610: I think AUthorityID is a MUST, since it is 
> required within the processing instructions t the client, is it not?
> 
> seciton 3 general: we may want to express versioning for 
> trusted res (or res in general), so that we can better 
> acommodate backwards compat, should XRIRes ever need 
> revisions (eg: application/xrid-t:1-saml:2.0+xml or 
> $res*trusted/XRITrusted/($v*1)). prehaps more broadly, do we 
> want to express a version in protocols as a general rule. 
> this is partially covered in 4.2.3, but i think it needs more 
> (perhaps _more_ is in the metadata spec, which i have not read yet ;-)
> 
> Section 5 Sec concerns forthcomming shortly (tomorrow mid-day)
> 
> --- peterd
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xri-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xri-help@lists.oasis-open.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xri-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xri-help@lists.oasis-open.org
> 
>