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] Possible changes to XRI 1.0


Fen-

	Let me respond inline


<snip> 
> Versioning -
> 
> As not all resolvers will be updated simultaneously, it seems 
> to me that 
> it would be useful to have a <ProtocolVersion> element that could 
> envelope new (or old) elements and tags.  Or is the xmlns tag 
> supposed 
> to be versioned?

The xmlns tag is supposed to be versioned, BUT this *may* be a different thing than versioning the Protocol. In other words, to promote backwards compatability, a newer version may use the basic structure of the original XRIDescriptor schema, with added extension elements. This would allow an older implementation to still interoperate at a 1.0 semantic level. 

Having a ProtocolVersion tag may be useful for pointing out XRI Authorities that speak newer versions of the protocol - and this would be independent of a rev'd version of the core XRIDescriptor namespace. 

> Service choice -
> 
> We have found that having e.g. multiple URIs within an XRID might not 
> always provide the best solution to accessing the available service. 
> For example, a broker may require HTTPS for authentication 
> but allow the 
> cheaper HTTP for other services it provides.  Is it expected 
> that this 
> issue would be handled by the requester via the service and 
> type tags? 

Thats was my intent. 

> Then what happens if the requester is asking for a 
> low-security (HTTP) 
> service but the broker only offers HTTPS for all its 
> services?  

The "broker" terminology isn't XRI. But I'll assume you mean the XRI Authority thats providing some local access service. In that case, each of the types of transport (HTTP vs HTTPS) could be described with different Service & Type tags. Why isn't this sufficient? 

Also, if the choice is between HTTPS and HTTP, I'd suggest you don't even need the type/service tags - the difference between HTTPS and HTTP service is obviously from the URL (ie the Local Access URL). 

> If the 
> requester could discover this, it could make use of the 
> available HTTPS 
> service rather than having to produce a "service not found" error.

I'm not following why the service & type tags in the XRIDescriptor aren't sufficient...


> Service query -
> 
> We might want to define a service, perhaps $r*a/QUERY, at 
> which address 
> lies a discovery service (UDDI or something else) that can be queried 
> and which would return the broker's available services.  Has 
> this been 
> considered and if so, would this be the proper way to implement it?

This is entirely reasonable, though I'm still not seeing the need for it. I would think it would be specified as an additional XRI local access service (ie in addition to X2R). In fact, we could even define UDDI access itself (with some means of processing the XRI into UDDI fields) as a local access service. 

This would NOT require rev'ing the core spec as the core spec explicitly says that new local access services can be defined outside the core spec. 

	-Gabe


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