OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Resolution Simplification


I always have been a pusher for the simplification, especially for writing things in terms of HTTP (since last fall). DDDS was much too complex, and required too much knowledge on behalf of the readers.

 

There is couple of things to think about though:

 

(1)     This proposal calls for at least several HTTP communications to potentially different host. This is a rather expensive operation. What would be the down side for letting the first contact server try to resolve the authority section in its entirety from the cache? (Non-authoritative answer).

(2)     In Gabe’s proposal, GET is used, but what about using POST? This allows more complex data to be sent from the client for query. For example, sending XML formatted request. This allows the extensibility as well as setting many options. It can incorporate the signature from the client as well. It is going to be a good hook for the security extension as well. More over, we may be able to make the resolution just another web service: same as other XNS services. This is better from the point of view of symmetry. Also, it is going to be less cryptic for the reader. This is a big gain.

 

Cheers,

 

Nat

 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent:
Thursday, September 04, 2003 3:26 AM
To: 'xri@lists.oasis-open.org'
Subject: [xri] Resolution Simplification

 

XRI Members-

    Its become rather clear to me that one of the impediments to getting feedback on the XRI spec is the density of the Resolution section and its reliance on DNS technologies thats folks are very unfamiliar with (e.g. DDDS).

 

    Towards the goal of getting XRI traction, I'm proposing a much simpler resolution process that focuses almost entirely on HTTP rather than trying to provide a framework for pluggable resolution. This proposal is 6 pages long (rather than the current 15-16 pages). No flowcharts!

 

    I've spoken with Dave McAlpin and we've got a pretty clear path for doing secure resolution with it as well. My proposal doesn't lay out those details, but rather suggests where the hooks are for doing secure resolution.

 

    I'm pretty confident that this simplification is a great step forward as it makes resolution a much more conventional process that relies more directly on HTTP.

 

    Please see the attached document and send feedback to the list or to myself. No decision has been made (obviously), but I'm hoping this proposal gets a general initial thumbs up. Its certainly a lot more understandable. Section 3.1 of the -07 draft is largely still applicable - so it might be useful to read that before you read this proposal.

 

    -Gabe



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]