ws: and wss: schemes

[Ian Hickson]

The formal registrations for the ws: and wss: schemes, part of the Web
Socket protocol, will be available in the Web Socket protocol ID as soon
as the IETF upload process completes:

   http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson wrote:
> The formal registrations for the ws: and wss: schemes, part of the Web
> Socket protocol, will be available in the Web Socket protocol ID as soon
> as the IETF upload process completes:
>
>    http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7

Looking at:

> 7.1. Registrarion of ws: scheme
>
>
>    URI scheme name.
>       ws
>
>    Status.
>       Permanent.
>
>    URI scheme syntax.
>       "ws" ":" hier-part [ "?" query ]

I assume you are using ABNF syntax (RFC5234) and terminology from the
URI spec, but you really need to state that.

>    URI scheme semantics.
>       The only operation for this scheme is to open a connection using
>       the Web Socket protocol.
>
>    Encoding considerations.
>       UTF-8 only.

What does this mean?

>    Applications/protocols that use this URI scheme name.
>       Web Socket protocol.
>
>    Interoperability considerations.
>       None.
>
>    Security considerations.
>       See "Security considerations" section above.
>
>    Contact.
>       Ian Hickson <ian@...>
>
>    Author/Change controller.
>       Ian Hickson <ian@...>
> ...

I believe that for a permanent registry on the standards track, change
control will have to move to IETF or IESG.

BR, Julian

[Julian Reschke]

Julian Reschke wrote:
> ...
>>    URI scheme syntax.
>>       "ws" ":" hier-part [ "?" query ]
>
> I assume you are using ABNF syntax (RFC5234) and terminology from the
> URI spec, but you really need to state that.
> ...

Furthermore I see no mention at all of these URI schemes in the
remainder of the spec. So is the IANA registration template supposed to
*be* the definition?

In particular:

1) What does a "ws" URI identify?

2) What is the semantics of "hier-part" and "query"?

BR, Julian

[David Booth-6]

On Fri, 2009-08-07 at 05:35 +0000, Ian Hickson wrote:
> The formal registrations for the ws: and wss: schemes, part of the Web
> Socket protocol, will be available in the Web Socket protocol ID as soon
> as the IETF upload process completes:
>
>    http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7
>

This looks to me like a perfect example of a case where a new scheme is
not needed, as the same thing can be accomplished by defining an http
URI prefix, as described in "Converting New URI Schemes or URN
Sub-Schemes to HTTP":
http://dbooth.org/2006/urn2http/
Note that I am talking about the *scheme*, not the protocol.  In
essence, a URI prefix such as "http://wss.example/" can be defined that
would serve the same purpose as a "wss:" scheme: an agent that
recognizes this prefix will know to attempt the WSS protocol.  But an
agent that doesn't *might* still be able to fall back to doing something
useful with the URI if it were an http URI, whereas it couldn't if it
were a "wss:" URI.

New schemes should not be created unless they are needed.  I think it
would be better to first implement this by defining an http URI prefix,
see what the adoption is, and then in a few years, *if* there is
widespread agent support for the protocol, then a new scheme may be
justified.


--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Ian Hickson]

On Fri, 7 Aug 2009, David Booth wrote:

>
> This looks to me like a perfect example of a case where a new scheme is
> not needed, as the same thing can be accomplished by defining an http
> URI prefix, as described in "Converting New URI Schemes or URN
> Sub-Schemes to HTTP":
> http://dbooth.org/2006/urn2http/
> Note that I am talking about the *scheme*, not the protocol.  In
> essence, a URI prefix such as "http://wss.example/" can be defined that
> would serve the same purpose as a "wss:" scheme: an agent that
> recognizes this prefix will know to attempt the WSS protocol.  But an
> agent that doesn't *might* still be able to fall back to doing something
> useful with the URI if it were an http URI, whereas it couldn't if it
> were a "wss:" URI.

This is only expected to be used from a WebSocket API call. What fallback
behaviour did you have in mind?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Maciej Stachowiak]

On Aug 7, 2009, at 1:22 AM, Greg Wilkins wrote:

> Julian Reschke wrote:
>
>> 1) What does a "ws" URI identify?
>
> Note also that ws is commonly used to denote Web Service.

I think it's unlikely the "ws" family of formats and protocols will  
want to register their own URI scheme. That being said, how about  
"wsp" for WebSocket Protocol?

  - Maciej

[Chris Anderson-13]

On Fri, Aug 7, 2009 at 3:14 PM, Maciej Stachowiak<mjs@...> wrote:

>
> On Aug 7, 2009, at 1:22 AM, Greg Wilkins wrote:
>
>> Julian Reschke wrote:
>>
>>> 1) What does a "ws" URI identify?
>>
>> Note also that ws is commonly used to denote Web Service.
>
> I think it's unlikely the "ws" family of formats and protocols will want to
> register their own URI scheme. That being said, how about "wsp" for
> WebSocket Protocol?

As long as we are throwing out acronyms, my suggestion would be for
the simple "websocket" or maybe "websock" if bytes are considered
expensive. I'm a big fan of the mailto: link b/c it's easy to
understand what it means.

Cheers,
Chris


--
Chris Anderson
http://jchrisa.net
http://couch.io

[David Booth-6]

On Fri, 2009-08-07 at 19:40 +0000, Ian Hickson wrote:

> On Fri, 7 Aug 2009, David Booth wrote:
> >
> > This looks to me like a perfect example of a case where a new scheme is
> > not needed, as the same thing can be accomplished by defining an http
> > URI prefix, as described in "Converting New URI Schemes or URN
> > Sub-Schemes to HTTP":
> > http://dbooth.org/2006/urn2http/
> > Note that I am talking about the *scheme*, not the protocol.  In
> > essence, a URI prefix such as "http://wss.example/" can be defined that
> > would serve the same purpose as a "wss:" scheme: an agent that
> > recognizes this prefix will know to attempt the WSS protocol.  But an
> > agent that doesn't *might* still be able to fall back to doing something
> > useful with the URI if it were an http URI, whereas it couldn't if it
> > were a "wss:" URI.
>
> This is only expected to be used from a WebSocket API call. What fallback
> behaviour did you have in mind?

I'm sure I could come up with some ideas, but I imagine those who have
been working on HTML5 could come up with much better ones.  I tried to
look in the HTML5 spec for some inspiration, but I find the word
"socket" appearing only once, in section 8.1:
http://dev.w3.org/html5/spec/Overview.html#event-definitions 
Where should I look for the info that gives the context for the
WebSocket API?  OTOH, protocols have a way of finding uses far beyond
those for which they were originally envisioned.  


--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[mnot]

My .02 -

websock seems like a good balance...


On 08/08/2009, at 10:52 AM, Chris Anderson wrote:

> On Fri, Aug 7, 2009 at 3:14 PM, Maciej Stachowiak<mjs@...>  
> wrote:
>>
>> On Aug 7, 2009, at 1:22 AM, Greg Wilkins wrote:
>>
>>> Julian Reschke wrote:
>>>
>>>> 1) What does a "ws" URI identify?
>>>
>>> Note also that ws is commonly used to denote Web Service.
>>
>> I think it's unlikely the "ws" family of formats and protocols will  
>> want to
>> register their own URI scheme. That being said, how about "wsp" for
>> WebSocket Protocol?
>
> As long as we are throwing out acronyms, my suggestion would be for
> the simple "websocket" or maybe "websock" if bytes are considered
> expensive. I'm a big fan of the mailto: link b/c it's easy to
> understand what it means.
>
> Cheers,
> Chris
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

--
Mark Nottingham     http://www.mnot.net/

[Jamie Lokier]

Ian Hickson wrote:

> On Fri, 7 Aug 2009, David Booth wrote:
> >
> > This looks to me like a perfect example of a case where a new scheme is
> > not needed, as the same thing can be accomplished by defining an http
> > URI prefix, as described in "Converting New URI Schemes or URN
> > Sub-Schemes to HTTP":
> > http://dbooth.org/2006/urn2http/
> > Note that I am talking about the *scheme*, not the protocol.  In
> > essence, a URI prefix such as "http://wss.example/" can be defined that
> > would serve the same purpose as a "wss:" scheme: an agent that
> > recognizes this prefix will know to attempt the WSS protocol.  But an
> > agent that doesn't *might* still be able to fall back to doing something
> > useful with the URI if it were an http URI, whereas it couldn't if it
> > were a "wss:" URI.
>
> This is only expected to be used from a WebSocket API call. What fallback
> behaviour did you have in mind?

Tunnelling WebSocket two-way communications over standard HTTP
messages, using any of the methods used for that, would be natural and
probably useful behaviour.

-- Jamie

[Julian Reschke]

Ian Hickson wrote:

> On Fri, 7 Aug 2009, David Booth wrote:
>> This looks to me like a perfect example of a case where a new scheme is
>> not needed, as the same thing can be accomplished by defining an http
>> URI prefix, as described in "Converting New URI Schemes or URN
>> Sub-Schemes to HTTP":
>> http://dbooth.org/2006/urn2http/
>> Note that I am talking about the *scheme*, not the protocol.  In
>> essence, a URI prefix such as "http://wss.example/" can be defined that
>> would serve the same purpose as a "wss:" scheme: an agent that
>> recognizes this prefix will know to attempt the WSS protocol.  But an
>> agent that doesn't *might* still be able to fall back to doing something
>> useful with the URI if it were an http URI, whereas it couldn't if it
>> were a "wss:" URI.
>
> This is only expected to be used from a WebSocket API call. What fallback
> behaviour did you have in mind?

Are you saying the URI scheme is *only* needed within WebSocket's API?
Why do you need a URI scheme in the first place, then?

BR, Julian

[David Booth-6]

On Fri, 2009-08-07 at 21:30 -0400, Daniel R. Tobias wrote:

> On 7 Aug 2009 at 9:16, David Booth wrote:
>
> > Note that I am talking about the *scheme*, not the protocol.  In
> > essence, a URI prefix such as "http://wss.example/" can be defined that
> > would serve the same purpose as a "wss:" scheme: an agent that
> > recognizes this prefix will know to attempt the WSS protocol.
>
> It seems like a bad idea to me, to have to build special exceptions
> to how a user agent processes URIs, where the protocol specified in
> the URI isn't actually the one that is used, based on "magic strings"
> within other parts than the scheme.

I can't see that as a significant issue, as there is only a trivial
difference between dispatching based on the string prefix
"http://wss.example/" and the string prefix "wss:".  Both are simple,
constant strings and both are equally "magic": they cause agent to
attempt the WSS protocol.



--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[David Booth-6]

On Sat, 2009-08-08 at 23:34 +0100, Jamie Lokier wrote:

> Ian Hickson wrote:
> > On Fri, 7 Aug 2009, David Booth wrote:
> > >
> > > This looks to me like a perfect example of a case where a new scheme is
> > > not needed, as the same thing can be accomplished by defining an http
> > > URI prefix, as described in "Converting New URI Schemes or URN
> > > Sub-Schemes to HTTP":
> > > http://dbooth.org/2006/urn2http/
> > > Note that I am talking about the *scheme*, not the protocol.  In
> > > essence, a URI prefix such as "http://wss.example/" can be defined that
> > > would serve the same purpose as a "wss:" scheme: an agent that
> > > recognizes this prefix will know to attempt the WSS protocol.  But an
> > > agent that doesn't *might* still be able to fall back to doing something
> > > useful with the URI if it were an http URI, whereas it couldn't if it
> > > were a "wss:" URI.
> >
> > This is only expected to be used from a WebSocket API call. What fallback
> > behaviour did you have in mind?
>
> Tunnelling WebSocket two-way communications over standard HTTP
> messages, using any of the methods used for that, would be natural and
> probably useful behaviour.

Sounds like a good idea to me, and an excellent reason to use an http
prefix instead of a new scheme.



--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Křištof Želechovski]

[1] specifically addresses the use case where the custom URL is presented to
a casual user.  Since there are no legitimate casual users of the Web
Sockets protocol that is designed to be used by Web applications only, there
are no benefits to introducing the additional complexity of using an http
alias.

 2.  Additionally, the proposed solution of using the URI prefix
"http://wss.example/" is suited for custom protocols, according to the
description at [1].  A protocol promulgated by the WWW Corporation can
hardly be viewed as custom.

IMHO,
Chris

[1] <URL:http://dbooth.org/2006/urn2http/>

-----Original Message-----
From: uri-review-bounces@... [mailto:uri-review-bounces@...] On
Behalf Of David Booth
Sent: Friday, August 07, 2009 3:17 PM
To: Ian Hickson
Cc: uri-review@...; hybi@...; uri@...
Subject: Re: [Uri-review] ws: and wss: schemes

On Fri, 2009-08-07 at 05:35 +0000, Ian Hickson wrote:
> The formal registrations for the ws: and wss: schemes, part of the Web
> Socket protocol, will be available in the Web Socket protocol ID as soon
> as the IETF upload process completes:
>
>    http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7
>

This looks to me like a perfect example of a case where a new scheme is
not needed, as the same thing can be accomplished by defining an http
URI prefix, as described in "Converting New URI Schemes or URN
Sub-Schemes to HTTP":
http://dbooth.org/2006/urn2http/
Note that I am talking about the *scheme*, not the protocol.  In
essence, a URI prefix such as "http://wss.example/" can be defined that
would serve the same purpose as a "wss:" scheme: an agent that
recognizes this prefix will know to attempt the WSS protocol.  But an
agent that doesn't *might* still be able to fall back to doing something
useful with the URI if it were an http URI, whereas it couldn't if it
were a "wss:" URI.

--
David Booth, Ph.D.

[Křištof Želechovski]

Whether the readability disadvantage of having a longer aliased prefix is
serious depends on how often such code has to be written or used.  If Web
application developers feel the need to say { ws+"host/path" } instead of {
"ws://host/path" }, the hypercorrectness has really gone over the edge.

IMHO,
Chris

-----Original Message-----
From: uri-review-bounces@... [mailto:uri-review-bounces@...] On
Behalf Of David Booth
Sent: Monday, August 10, 2009 3:52 AM
To: Daniel R. Tobias
Cc: uri-review@...; hybi@...; uri@...
Subject: Re: [Uri-review] ws: and wss: schemes

I can't see that as a significant issue, as there is only a trivial
difference between dispatching based on the string prefix
"http://wss.example/" and the string prefix "wss:".  Both are simple,
constant strings and both are equally "magic": they cause agent to
attempt the WSS protocol.



--
David Booth, Ph.D.

[noah_mendelsohn]

Kristof Zelechovski

> Since there are no legitimate casual users of the Web
> Sockets protocol that is designed to be used by Web applications only,
there
> are no benefits to introducing the additional complexity of using an
http
> alias.

Well, there is at least one small cost avoided by using http rather than
allocating new scheme names, which is that those names remain available
for use by others.  Right now, it's not to hard to find sensible short
names for the few URI schemes that pop up, but over what will likely be
decades if not centuries of use of the Web, there may be value in avoiding
unnecessary allocations.

Furthermore, some would argue that there is benefit from the fact that
deployed HTTP infrastructure can be used to obtain information about these
resources, should one wish to (and I understand that, at this point, such
a need is not anticipated).

I'm not offering an opinion just now as to whether the new schemes are on
balance a good thing, just adding to the lists of pros and cons.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Kristof Zelechovski <giecrilj@...>
Sent by: uri-request@...
08/11/2009 12:35 PM
 
        To:     "'David Booth'" <david@...>, "'Ian Hickson'"
<ian@...>
        cc:     <uri-review@...>, <hybi@...>, <uri@...>,
(bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: [Uri-review] ws: and wss: schemes


[1] specifically addresses the use case where the custom URL is presented
to
a casual user.  Since there are no legitimate casual users of the Web
Sockets protocol that is designed to be used by Web applications only,
there
are no benefits to introducing the additional complexity of using an http
alias.

 2.  Additionally, the proposed solution of using the URI prefix
"http://wss.example/" is suited for custom protocols, according to the
description at [1].  A protocol promulgated by the WWW Corporation can
hardly be viewed as custom.

IMHO,
Chris

[1] <URL:http://dbooth.org/2006/urn2http/>

-----Original Message-----
From: uri-review-bounces@... [mailto:uri-review-bounces@...] On
Behalf Of David Booth
Sent: Friday, August 07, 2009 3:17 PM
To: Ian Hickson
Cc: uri-review@...; hybi@...; uri@...
Subject: Re: [Uri-review] ws: and wss: schemes

On Fri, 2009-08-07 at 05:35 +0000, Ian Hickson wrote:
> The formal registrations for the ws: and wss: schemes, part of the Web
> Socket protocol, will be available in the Web Socket protocol ID as soon

> as the IETF upload process completes:
>
>    http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7
>

This looks to me like a perfect example of a case where a new scheme is
not needed, as the same thing can be accomplished by defining an http
URI prefix, as described in "Converting New URI Schemes or URN
Sub-Schemes to HTTP":
http://dbooth.org/2006/urn2http/
Note that I am talking about the *scheme*, not the protocol.  In
essence, a URI prefix such as "http://wss.example/" can be defined that
would serve the same purpose as a "wss:" scheme: an agent that
recognizes this prefix will know to attempt the WSS protocol.  But an
agent that doesn't *might* still be able to fall back to doing something
useful with the URI if it were an http URI, whereas it couldn't if it
were a "wss:" URI.

--
David Booth, Ph.D.

[Křištof Želechovski]

The Web Socket API is currently described by
<URL:http://www.whatwg.org/specs/web-workers/current-work/>.
HTH,
Chris

-----Original Message-----
From: uri-review-bounces@... [mailto:uri-review-bounces@...] On
Behalf Of David Booth
Sent: Saturday, August 08, 2009 2:22 AM
To: Ian Hickson
Cc: uri-review@...; hybi@...; uri@...
Subject: Re: [Uri-review] ws: and wss: schemes

Where should I look for the info that gives the context for the
WebSocket API?  OTOH, protocols have a way of finding uses far beyond
those for which they were originally envisioned.  


--
David Booth, Ph.D.

[David Booth-6]

On Tue, 2009-08-11 at 18:35 +0200, Kristof Zelechovski wrote:
> 1.  The document "Converting New URI Schemes or URN Sub-Schemes to HTTP"
> [1] specifically addresses the use case where the custom URL is presented to
> a casual user.  Since there are no legitimate casual users of the Web
> Sockets protocol that is designed to be used by Web applications only, there
> are no benefits to introducing the additional complexity of using an http
> alias.

I respectfully disagree.  I think it is a virtual certainty that if the
WSS protocol is useful, it will be used in ways far beyond its original
intent.  I don't think it would be wise to artificially constrain the
applicability of a new protocol by claiming that casual users are not
'legitimate'.

>
>  2.  Additionally, the proposed solution of using the URI prefix
> "http://wss.example/" is suited for custom protocols, according to the
> description at [1].  A protocol promulgated by the WWW Corporation can
> hardly be viewed as custom.

I don't know exactly what you mean by "custom protocol", but WSS is
*exactly* the kind of protocol that [1] was talking about.  The
introduction uses "XyzConsortium" as an example, but you can think "WWW
Corporation" instead.

David

>
> IMHO,
> Chris
>
> [1] <URL:http://dbooth.org/2006/urn2http/>
>
> -----Original Message-----
> From: uri-review-bounces@... [mailto:uri-review-bounces@...] On
> Behalf Of David Booth
> Sent: Friday, August 07, 2009 3:17 PM
> To: Ian Hickson
> Cc: uri-review@...; hybi@...; uri@...
> Subject: Re: [Uri-review] ws: and wss: schemes
>
> On Fri, 2009-08-07 at 05:35 +0000, Ian Hickson wrote:
> > The formal registrations for the ws: and wss: schemes, part of the Web
> > Socket protocol, will be available in the Web Socket protocol ID as soon
> > as the IETF upload process completes:
> >
> >    http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7
> >
>
> This looks to me like a perfect example of a case where a new scheme is
> not needed, as the same thing can be accomplished by defining an http
> URI prefix, as described in "Converting New URI Schemes or URN
> Sub-Schemes to HTTP":
> http://dbooth.org/2006/urn2http/
> Note that I am talking about the *scheme*, not the protocol.  In
> essence, a URI prefix such as "http://wss.example/" can be defined that
> would serve the same purpose as a "wss:" scheme: an agent that
> recognizes this prefix will know to attempt the WSS protocol.  But an
> agent that doesn't *might* still be able to fall back to doing something
> useful with the URI if it were an http URI, whereas it couldn't if it
> were a "wss:" URI.
>

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Křištof Želechovski]

A "custom protocol" is, using David's terms, an owner-dependent protocol,
whereas a "standard protocol" is an owner-independent protocol.  "Owner" is
the owner of the aliasing domain.  A protocol is owner-dependent if the
server is guaranteed to belong to the owner (e.g. a bank or an ISP).
HTH,
Chris

-----Original Message-----
From: David Booth [mailto:david@...]
Sent: Tuesday, August 11, 2009 11:19 PM
To: Kristof Zelechovski
Cc: 'Ian Hickson'; uri-review@...; hybi@...; uri@...
Subject: RE: [Uri-review] ws: and wss: schemes

On Tue, 2009-08-11 at 18:35 +0200, Kristof Zelechovski wrote:
>
>  2.  Additionally, the proposed solution of using the URI prefix
> "http://wss.example/" is suited for custom protocols, according to the
> description at [1].  A protocol promulgated by the WWW Corporation can
> hardly be viewed as custom.

I don't know exactly what you mean by "custom protocol", but WSS is
*exactly* the kind of protocol that [1] was talking about.  The
introduction uses "XyzConsortium" as an example, but you can think "WWW
Corporation" instead.

David

[Maciej Stachowiak]

On Aug 9, 2009, at 6:52 PM, David Booth wrote:

> On Fri, 2009-08-07 at 21:30 -0400, Daniel R. Tobias wrote:
>> On 7 Aug 2009 at 9:16, David Booth wrote:
>>
>>> Note that I am talking about the *scheme*, not the protocol.  In
>>> essence, a URI prefix such as "http://wss.example/" can be defined  
>>> that
>>> would serve the same purpose as a "wss:" scheme: an agent that
>>> recognizes this prefix will know to attempt the WSS protocol.
>>
>> It seems like a bad idea to me, to have to build special exceptions
>> to how a user agent processes URIs, where the protocol specified in
>> the URI isn't actually the one that is used, based on "magic strings"
>> within other parts than the scheme.
>
> I can't see that as a significant issue, as there is only a trivial
> difference between dispatching based on the string prefix
> "http://wss.example/" and the string prefix "wss:".  Both are simple,
> constant strings and both are equally "magic": they cause agent to
> attempt the WSS protocol.

The difference is that "http://wss.example/" already has a meaning,  
which is not the intended one. Whereas "wss:" currently has no  
meaning. Thus the former has greater risk of either colliding with an  
existing resource, or being misinterpreted by a legacy client (instead  
of just rejected).

Regards,
Maciej