[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Type and Media parameters
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]