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

["Drummond Reed" <drummond.reed@cordance.net>]

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