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

[Peter C Davis <peter.davis@neustar.biz>]

BTW, these line ref's are from the PDF version ;-)

On Monday 28 February 2005 04:26 pm, Peter C Davis wrote:
> 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