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


Dave McAlpin wrote:

Thank you, Dave, for an excellent summary of proposed changes.  One 
omission is the proposal to define '*' as the sole delegation character. 
  This would make parsers easier to write, XRIs easier to read, and 
plays nicely against the single hierarchy character '/'.  But I'll leave 
further discussion of this point to Drummond.

I do have a suggestion and a couple related questions, though.  Forgive 
me if I am missing things that are (clearly?) in the spec as I am still 
a novice at XRI resolution.

> -- New XRIDescriptor elements
>  
> There are several XRID elements added by the trusted res draft that are 
> potentially useful in standard resolution. We should evaluate and 
> include as needed.

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?

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? 
Then what happens if the requester is asking for a low-security (HTTP) 
service but the broker only offers HTTPS for all its services?  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.

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?

Thanks,
Fen


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