[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]