Re: [xri] XRDS media type

[Peter Davis <peter.davis@neustar.biz>]

+1

=peterd

On Sep 16, 2009, at 5:46 PM, Markus Sabadello wrote:

> Maybe we could use a subtype, like we had already been doing. E.g.  
> in XRI 2.0 we have something like this:
>
> application/xrd+xml;sep=false;ref=true
>
> We could invent a new subtype "xrds", e.g:
>
> application/xrd+xml;sep=false;ref=true;xrds=true
>
> If it's true it means you want the full XRDS. If it's false or  
> absent, you just want the final XRD.
>
> Markus
>
> On Wed, Sep 16, 2009 at 10:33 PM, John Bradley <jbradley@mac.com>  
> wrote:
> 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
>
>
>
> ---------------------------------------------------------------------
> 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
>

Peter Davis: Neustar, Inc.
Director & Distinguished Member of the Technical Staff
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ 
  [X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for  
the use of the recipient(s) named above and may contain confidential  
and/or privileged information. If you are not the intended recipient  
you have received this e-mail message in error and any review,  
dissemination, distribution, or copying of this message is strictly  
prohibited. If you have received this communication in error, please  
notify us immediately and delete the original message.