RE: [xri] Type and Media parameters

["Tan, William" <William.Tan@neustar.biz>]

I can understand your concern from the aesthetics standpoint. However, I
think for interoperability, it is best leaving it encoded. I can think
of a few reasons for that (need further investigation):

1. The HXRI may be an invalid URI if gen-delims such as ":" or "@"
appears in the URI fragment. That is how I read the ABNF of RFC3986. I
suspect most URI parsers are more lenient and would allow any character
other than "&", "#" and "=", it may break certain stricter parsers.

2. From an implementation standpoint, I think it is also easier to have
the CGI library URI-decode the parameters rather than implementing it
from scratch.

Wil. 
 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Thursday, December 29, 2005 10:54 AM
> To: 'Wachob, Gabe'; 'Victor Grey'; xri@lists.oasis-open.org
> Subject: RE: [xri] Type and Media parameters
> 
> My understanding of Victor's proposal is that it is for both HXRI
query
> parameters and HTTP headers, and that if both were present, the former
> takes
> precedence.
> 
> That said, my main question is whether all the escaping is necessary
in
> the
> query string. That sure is one massively ugly string.
> 
> Is that really necessary given that an HXRI is only ever processed by
an
> XRI-aware agent? That's what we decided with regards to putting a QXRI
in
> the path portion of an HXRI. I don't see why that wouldn't apply here
as
> well.
> 
> =Drummond
> 
> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Wednesday, December 28, 2005 10:14 AM
> To: Victor Grey; xri@lists.oasis-open.org
> Subject: RE: [xri] Type and Media parameters
> 
> Does this actually satisfy requirements?
> 
> I thought the reason people wanted to put service type in the HTTP URI
> is to have a link to a particular service in an HXRI. With the
> pragma/accept headers, you can't specify this in a HTTP URI...
> 
> 	-Gabe
> 
> > -----Original Message-----
> > From: Victor Grey [mailto:victor@idcommons.org]
> > Sent: Tuesday, December 27, 2005 8:08 PM
> > To: xri@lists.oasis-open.org
> > Subject: [xri] Type and Media parameters
> >
> > As promised, here's my strawman proposal for a way for an xri
> > resolver
> > client to specify type and media parameters in a request.
> >
> > The parameters can be specified in either a query string,
> > url-encoded
> > and  appended to the HXRI, or in the HTTP header (or both).
> > If a type
> > or media parameter is transmitted in both header and query
> > string, the
> > query string value will take precedence.
> >
> > In the HTTP header, I propose that we use the Accept field for media
> > type (which is fairly standard) and the Pragma field for the service
> > type (here I am on more shaky ground. Based my choice on
> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32  -
> > comments solicited).
> >
> > Examples---
> > In the HTTP header:
> > Accept: text/html
> > Pragma: xri_servicetype=xri://+contact*($v1.1)
> >
> > Same thing in the query string:
> > xri_servicetype=xri%3A%2F%2F%2Bcontact%2A%28%24v1.1%29&xri_med
> > iatype=tex
> > t%2Fhtml
> > or for readability here it is before url-encoding:
> > xri_servicetype=xri://+contact*($v1.1)&xri_mediatype=text/html
> >
> >
> > If the HXRI contains an existing query string, the type and/or media
> > parameters are appended to the existing query string with an "&".
> > Otherwise the type and/or media parameters are appended to the path
> > with an "?'. The order of the key/value pairs in a URI query
> > string is
> > not significant.
> >
> > Regards,
> > =vg
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all
> > your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > oups.php
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and 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.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php