headers
Sebastian Pipping | 8 Nov 21:22

uriparser 0.7.3 released


Hello!

This release offers a wild mix of things.  Mainly it makes uriparser
build on Cygwin (packager wanted!), fixes a small bug with parsing
reported by Sezai Tekin, and adds Qt Compressed Help (.qch) output
for viewing the API documentation in Qt Assistant.
This release is both source- and binary-compatible.

Download:
http://sourceforge.net/project/showfiles.php?group_id=182840

Changelog:
http://sourceforge.net/project/shownotes.php?release_id=639066&group_id=182840

Sebastian
Permalink | Reply | 0 comments |
headers
Robert Brewer | 6 Nov 23:00
Favicon
Gravatar

Re: URI Templates: done or dead?


Roy Fielding wrote:
> Something like
>
>    var   = "value";
>    undef = null;
>    empty = "";
>    list  = [ "val1", "val2", "val3" ];
>    keys  = [ "key1", "val1", "key2", "val2", "key3", "val3" ];
>    path  = "/foo/bar"
>    x     = "1024";
>    y     = "768";
>
> {var}                     value
> {var=default}             value
> {undef=default}           default
> {var:3}                   val
> {x,y}                     1024,768
> {?x,y}                    ?x=1024&y=768
> {?x,y,empty}              ?x=1024&y=768&empty=
> {?x,y,undef}              ?x=1024&y=768
> {;x,y}                    ;x=1024;y=768
> {;x,y,empty}              ;x=1024;y=768;empty
> {;x,y,undef}              ;x=1024;y=768
> {/list,x}                 /val1/val2/val3/1024
> {+path}/here              /foo/bar/here
> {+path,x}/here            /foo/bar,1024/here
> {+path}{x}/here           /foo/bar1024/here
> {+empty}/here             /here
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Connolly | 4 Nov 16:28

Re: Fwd: Mac number and IP address as URIs


Lisa Dusseault wrote:
> Ted Hardie reminded me to ask this here as well...
[...]
>>> Has anybody else used or seen URIs that serve to carry mac addresses
>>> and IP addresses?  This draft defines new formats;

I've seen dns: and tcp: in the REBOL stuff, but not ip: nor mac:

I just did a little gardening in a wiki of URI schemes...

   http://esw.w3.org/topic/UriSchemes/dns
   http://esw.w3.org/topic/UriSchemes/ip
   http://esw.w3.org/topic/UriSchemes/mac

>>> http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-held-identity-extensions-07.txt
>>>
>>> Lisa
>>
>> The URI and uri-review lists would also be good places to ask this...

--

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Permalink | Reply | 0 comments |
headers
Claes H | 9 Oct 21:44

How to encode URL for HTTP over unix domain sockets?


Hello,

What would be a good way to encode URLs for communication using HTTP
over Unix domain sockets? For example to implement a service locally:
Rather than serving it from http://www.example.com/service, to do it
from a socket on the file system named /tmp/daemon.socket

>From my understanding of RFC 3986, the file system path must somehow
be encoded as the 'host' part of the authority, in a way that can not
be confused with domain name addresses or IP addresses. So lets say we
would put a character from sub-delims in front, such as '!', to make
it invalid as any current HTTP URL. Then we get !/tmp/daemon.socket.
Next we percent-encode it and add the scheme and path parts. Then we
get

http://!%2Ftmp%2Fdaemon.socket/service

Playing a little bit with sub-delims, here are some variants:

http://filesystem,%2Ftmp%2Fdaemon.socket/service

http://socket;%2Ftmp%2Fdaemon.socket/service

Have I interpreted the specs correctly? Of course, this is not
compliant with HTTP as defined by RFC2616, but I am curious about
valid ways to extend this.

Background: I have for a while wondered why HTTP is rarely used for
local RPC, since it is has been so successful on the Internet. Using
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Nottingham | 15 Sep 13:54

URI Templates: done or dead?


There hasn't been a lot of discussion or activity on URI Templates  
recently, which either means it's very stable, or very nearly dead.

If it's very stable, we should ship it and be done with it. If it's  
nearly dead (and I do get a whiff of that; while I continuously hear  
people clamouring for it to be finished, not many seem to be willing  
to use it in its current state; YMMV), we should at least try to  
revive it.

My continuing concerns with the -03 draft are that it's too complex,  
not human-friendly, and it makes the common, simple use cases hard.  
The first example in the spec ( http://www.example.com/users/ 
{userid} ) holds up well, but it goes quickly downhill from there; ( http://www.example.com/? 
{-join|&|query,number} ) looks like line noise, IMHO.

I believe there are a few things we can do to make URI Template more  
broadly useful and useable, without sacrificing too much functionality  
(at least in the 80% case).

1. Reduce or drop operators.

As mentioned above, they don't read well; they're obviously intended  
for machines, not people. The expansion for a template should be  
blindingly obvious, but the operator syntax seems to want to get in  
the way rather than help. Furthermore, the vast majority of use cases  
for templates are for simple template substitution, not operations  
like 'neg' and 'opt'.

2. Drop list values.
(Continue reading)

Permalink | Reply | 26 comments |
headers
Sebastian Pipping | 1 Sep 19:06

uriparser 0.7.2 released


Hello!

This release fixes bad cleanup logic in two functions
related to URI reference creation and resolution.
Depending on your usage of these functions the result
could have been either a crash or a memleak, so updating
is strongly recommended.
This release is both source- and binary-compatible.

Download:
http://sourceforge.net/project/showfiles.php?group_id=182840

Changelog:
http://sourceforge.net/project/shownotes.php?release_id=623493

Sebastian
Permalink | Reply | 0 comments |
headers
Erik Wilde | 30 Aug 01:06
Favicon

submission of "draft-wilde-sms-uri-16"


dear i-d editor.

with this email i would like to update the internet draft entitled "URI 
Scheme for GSM Short Message Service".

this new version of draft-wilde-sms-uri updates draft-wilde-sms-uri-15. 
the text and html versions of the submitted draft can be found at the 
following locations:

http://dret.net/netdret/docs/draft-wilde-sms-uri-16.txt
http://dret.net/netdret/docs/draft-wilde-sms-uri-16.html

the draft's abstract reads:

This memo specifies the Uniform Resource Identifier (URI) scheme "sms" 
for specifying one or more recipients for an SMS message. SMS messages 
are two-way paging messages that can be sent from and received by a 
mobile phone or a suitably equipped networked device.

thanks a lot and kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret <at> berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)
Permalink | Reply | 0 comments |
headers
Julian Reschke | 22 Jul 14:05

heldref URI scheme


Hi,

has anybody over here reviewed this?

<http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-08#section-8>

BR, Julian
Permalink | Reply | 4 comments |
headers
Erik Wilde | 30 Jun 08:58
Favicon

percent-encoding in tel URIs


hello.

i am currently rewriting the sms URI scheme draft with the goal to reuse 
the phone number definition in the tel URI scheme. the problem is that 
the tel URI scheme is extremely permissive and allows all URI characters 
in its isdn-subaddress syntax part. however, the way i am reading the 
spec, all URI reserved characters have to be percent-encoded when 
appearing in an isdn-subaddress. is that correct? i am asking this 
because i need some separator in the sms URI scheme for a sequence of 
phone numbers (if a SMS should be sent to more than one receiver). the 
current syntax uses ",". the way i am reading the tel URI scheme spec, i 
can still use the "," in the sms URI scheme, and "," in its literal form 
will separate phone numbers, whereas "," as part of a isdn-subaddress 
has to be percent-encoded. is that correct?

tel URI scheme RFC: http://tools.ietf.org/html/rfc3966
sms URI scheme draft: 
http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-15.txt

thanks a lot,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret <at> berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)
Permalink | Reply | 8 comments |
headers
Ian Hickson | 29 Jun 12:57

URIs in HTML5 and issues arising

On Wed, 25 Jun 2008, John Cowan wrote:
>
> Ian Hickson scripsit:
> 
> > I think that the confusion of introducing a new term would be greater 
> > than the confusion of reusing URL. People intuitively know what a 
> > "URL" basically is, and they know what an "address" is. They don't 
> > know what an "HRI" is and I think that would work against the 
> > readability of the spec. (This is especially important for this 
> > particular term since it appears all over the place in HTML5.)
> 
> Fair enough.  Use "HTML URL" a few times, then, particularly in the 
> context of the definition of validity.

It was pointed out that "HTML URL" would also be misleading, since there 
are already spec writers looking to use these definitions elsewhere.

On Thu, 26 Jun 2008, Felix Sasaki wrote:
> >
> > It was brought to my attention on IRC that "address" is probably as 
> > overloaded as "URL" so this might not be a step forwards for the spec, 
> > just a step sideways. I'll see what can be done though. It might be 
> > that the spec just uses the term "URL" and ignores the URI spec's 
> > definition of the term.
> 
> There is an alternative to ignoring the URI spec's definition: describe 
> your usage of "URL" and the usage as intended by the URI spec. See a 
> similar problem and a solution for the usage of the terms "URI" and 
> "IRI" mentioned at 
> http://lists.w3.org/Archives/Public/www-tag/2008Jun/0110.html
(Continue reading)

Permalink | Reply | 23 comments |
headers
Frank Ellermann | 26 Jun 22:36

Re: Error handling in URIs


Felix Sasaki wrote:

> http://lists.w3.org/Archives/Public/www-tag/2008Jun/0110.html
[...]
> the above link points to an approach of not munging IRI and
> URI, but making the difference clear.

That's not how I interpret "extended".  I'm sorry to note it,
but when the word "extend" already gets me in full combat
mode then something else in this mail doesn't help.  Quoting
RFC 3987, fifth statement in the abstract on page one:

| The approach of defining a new protocol element was chosen
| instead of extending or changing the definition of URIs. 
  ^^^^^^^^^^^^^^^^^^^^
IMO anything else would not be published on standards track 
without IAB review.  

> different communities have established different terminology.

Sure, I didn't doubt that such newspeak has a purpose, but it
is hostile to users.  They will upgrade their OS and browsers
when they are ready for it.  Not because the browser industry
redefines the term URL, and then claims that it is the fault
of the users if their old software "only" implements STD 66.

> See also Henry's mail

I'm fine with saying "URL" colloquially, outside of standards,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane