[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] XRDS media type
For the proxy resolver the mime types are passed as a query string, and not by content negotiation. I think for the registration we can concentrate on the current use. We have to deal with versioning on the proxy server anyway. John B. On 2009-09-16, at 3:42 PM, Eran Hammer-Lahav wrote: > You can always use something else other than Accept header to make > this query different. > > But the issue here is about registration. If we register both, we > need to deal with the existing (and incompatible) use of application/ > xrds+xml. We need to list all the existing applications using it, > detail interoperability issues, etc. This is not impossible but it > is not fun either. The current deployed expectation for application/ > xrds+xml is to get an XRDS (2.0) document. We will need to address it. > > Since we are using the same namespace, it would be perfectly legal > to return an XRDS (XRD 1.0) document for the xrd+xml mime type. My > question is if that is enough? If the only use case is the one > provided below, I think the right solution is to change the resolver > interface and not register the xrds+xml type. > > I don't feel strongly about this. > > EHL > >> -----Original Message----- >> From: Drummond Reed [mailto:drummond.reed@cordance.net] >> Sent: Wednesday, September 16, 2009 12:35 PM >> To: 'XRI TC' >> Cc: 'John Bradley' >> Subject: RE: [xri] XRDS media type >> >> I missed the start of this thread, but here's the specific use case I >> can >> speak to for XRI Resolution 3.0: >> >> In some cases an XRD consumer (acting as an XRI 3.0 resolver) will >> want >> to >> request JUST an XRD from an XRD provider (acting as an XRI 3.0 >> authority). >> That means that no matter how many XRI 3.0 resolution steps (linked >> XRDs) >> the provider needs to request, the consumer only wants the final XRD >> back. >> >> In this case the XRD consumer can make a request asking for content- >> type >> application/xrd+xml. >> >> In other cases the XRD consumer may want the entire sequence of XRDs >> retrieved by the XRD provider. In this case the XRD consumer can >> make a >> request asking for content-type application/xrds+xml. >> >> So, unless I'm missing something, we actually need both mime types. >> >> =Drummond >> >>> -----Original Message----- >>> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] >>> Sent: Tuesday, September 15, 2009 6:58 PM >>> To: Scott Cantor; 'XRI TC' >>> Subject: RE: [xri] XRDS media type >>> >>> Yes, there was which is actually used already (application/xrds >>> +xml). >> This >>> is why I am asking because if we register both, we will need to deal >> with >>> the existing deployment which is not compliant. So I rather just >> register >>> one. >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: Scott Cantor [mailto:cantor.2@osu.edu] >>>> Sent: Tuesday, September 15, 2009 6:54 PM >>>> To: Eran Hammer-Lahav; 'XRI TC' >>>> Subject: RE: [xri] XRDS media type >>>> >>>> Eran Hammer-Lahav wrote on 2009-09-15: >>>>> I am assuming that a document with a root of <XRDS> but using the >> XRD >>>> XML >>>>> namespace is considered application/xrd+xml and not >>>> application/xrds+xml... >>>>> >>>>> Since they both use the same schema. >>>> >>>> They don't have to, but it's typical to do that. >>>> >>>> Was there a media type for the original XRDS? >>>> >>>> Either way it's confusing, I guess. >>>> >>>> -- Scott >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis- >> open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/ >> my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]