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: Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-02-19


Following are the minutes of the unofficial telecon of the XRI TC at:

Date:  Thursday, 19 February 2009 USA
Time:  2:00PM - 3:00PM Pacific Time (22:00-23:00 UTC)

ATTENDING

John Bradley
Markus Sabadello
Peter Davis
Drummond Reed
Breno de Medeiros
Eran Hammer-Lahav

REGRETS

Nick Nicholas



1) XRD 1.0 - HOST META

Eran said he is still seeking feedback on the draft.
	
	
http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-01.txt

# ALL - please review and post feedback.


2) XRD 1.0 - HTTP DISCOVERY

The same is true for this draft.

	http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt

# ALL - please review and post feedback.


3) XRD 1.0 - DNS DISCOVERY

Peter is still progressing.


4) XRD 1.0 - SCHEMA

	http://wiki.oasis-open.org/xri/XrdOne/XrdSchema

We discussed the example Eran posted to the list of how OpenID discovery
would work. 

	http://lists.oasis-open.org/archives/xri/200902/msg00074.html 

John suggested another option besides the one-level redirection that Eran's
example shows. The use case is users who want to delegate to service
providers to maintain the XRD for a whole set of services, i.e., "For the
list of services my service provider offers me, go look over there."

From one perspective, this may be looked at as a "redirect" to another XRD
in an different context. Drummond suggested this is like having a <Link>
with a <Rel>describedBy</Rel> relationship - similar to the <Ref> element in
XRI Resolution 2.0. 

However John was thinking of something more specific, i.e., something where
the Rel semantics were something like "service-provider" or
"meta-service-provider". 

Breno suggested that such a service provider might also aggregate XRD
discovery information from other service providers on behalf of the user. So
the service provider may not be authoritative for all the metadata.

Peter said that a service provider also needs to be able to perform
delegation of their own services, e.g., Google may want to delegate specific
services from google.com to mail.google.com and xmpp.google.com. Breno
agreed but said that the trust issues of such delegation are important.

John believes it is in the scope of the XRD spec to define some generic
<Rel> values that pertain to discovery. This would avoid interop issues of
different applications trying to define their own <Rel> values for generic
discveroy relationships.

Drummond summarized it this way:

Most general <Rel> (just a pointer to another XRD): describedBy
Most specific <Rel>: a concrete service URI
John's requested <Rel>: semantics expressing the set of services from a
service provider.


5) XRD 1.0 - SCHEMA EXTENSION OPTIONS

We discussed Eran's email enumerating the options for application-specific
metadata extensions ("alternate ways to extend resource attributes"):

	http://lists.oasis-open.org/archives/xri/200902/msg00073.html 

Eran's conclusion was that without any changes to the schema, there are at
least three clear ways to extend it (#1, #2, #7), plus two more (#3, #4)
than do not require a schema change but require defining <Rel> semantics (or
the lack thereof). Only #5 and #6 require schema changes.

RE #5 and #6, there was concensus that keeping the schema simple and flat is
preferred, so those should be eliminated.

RE #3 and #4, Eran explained that Atom has <Rel>self</Rel>, but that it
actually means alias as defined by IANA. We already have that semantics in
the <Alias> element.

A Link with no <Rel> is undefined, as was also true of XRI Resolution 2.0.
But with XRI Resolution 2.0, the semantics of the <Link> element (then
<Service> element) were defined to be those of the value of the <URI> child
element, i.e., an http: URI meant that there was an HTTP service available.

Eran felt that the semantics of a <Link> with no <Rel> element should remain
undefined.

John also suggested that we might define an attribute of <Link> that
indicates whether it is a pointer to another XRD or whether it is terminal
(i.e., further discovery on the linked resource should NOT be performed).
Eran explained that that could accomplished via two different <Rel> URIs.
John said that a "nofollow" attribute would allow specifications using XRD
for discovery to only need to define one URI. We agreed both mechanisms
would work, and we should see which one appears more intuitive.


6) XRD 1.0 - TRUST TEAM

Brian and Nat could not attend so we skipped this topic.


7) XRI 3.0 - SYNTAX AND BINDINGS UPDATE

Drummond is still waiting for time to tackle a draft; Nick was travelling.
 

8) CANCELLING TUESDAY CALLS

There was concensus that we are moving solidly enough that the time taken
for the Tuesday call is better put towards spec and issues progress, and
that we should instead call for special topic telecons as needed to close
specific issues. So we will return to just holding calls on Thursdays at the
regular time, 2-3PM PT (22:00-23:00 UTC).




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