Subject: [hybi] charter question/feedback

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 23 Sep 2009 10:11:41 +0200

Is there any impact of not meeting all deliverables on other deliverables?

I think the long term solution should also have a Web browser buy-in  
clause.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 23 Sep 2009 18:42:52 +0300

Hi Anne,

thanks for the comments. See my answers in line.

cheers
Sal

> Is there any impact of not meeting all deliverables on other 
the short-term and long term deliverables are independent at least in my 
opinion!
> I think the long term solution should also have a Web browser buy-in 
I completely agree that Web browsers have to be keep in consideration 
but I do not think
it should be the only possible client environment.
What about something like:

In the long term, new features will be required of clients, servers, or
intermediaries allowing a more scalable and robust end-to-end experience.
Web browser is envisioned to be the preferred client environment for long term solution,
however the same long term solution features should be accessible also to no web based clients.

That is just a possibility, feel free to provide a text for it.

cheers
Sal

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 24 Sep 2009 10:28:18 +0200

> That is just a possibility, feel free to provide a text for it.

Thanks, what I was thinking of was something like: "Adoption by two or  
more Web browsers is required, though the solution should also be suitable  
for other clients."

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 24 Sep 2009 14:56:05 +0300

thanks Anne, for the text, I would just slightly modify it in:

"Adoption by two or more Web browsers is required, though the solution 
should also be suitable for clients other than Web Browser."

/Sal

Anne van Kesteren wrote:
> more Web browsers is required, though the solution should also be 
> suitable for other clients."
>
>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 24 Sep 2009 14:00:23 +0200

> should also be suitable for clients other than Web Browser."

Sounds good to me!

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Sep 2009 14:02:32 +0200

Salvatore Loreto wrote:
> ...

Does that mean that the WG wouldn't be allowed to submit a spec unless 
it has buy-in from at least two Web browsers? If so, which qualify? Do 
Lynx, iCab, or Amaya count?

BR, Julian

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 24 Sep 2009 08:22:23 -0600

> Lynx, iCab, or Amaya count?

We shouldn't need buy-in for the short term solution, or it's not the short
term solution.  Perhaps "applicability" or "implementability"?

For the long term, we could say "suitability for wide adoption by web
browsers".

-- 
Joe Hildebrand

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 24 Sep 2009 17:31:55 +0300

the proposed text is for long term solution...

and it should go just after the current text:

"In the long term, new features will be required of clients, servers, or
intermediaries allowing a more scalable and robust end-to-end experience."

"Adoption by two or more Web browsers is required, though the long term solution
should also be suitable for clients other than Web Browser."

I think the important here is a proof of concept (through one/two or 
more running code) that client side of
the long term solution works well both in Web Browser and not Web 
Browser environment.

Maybe we can change from "Adoption by two or more Web browser" in
"Implementation /Adoption in two or more Web Browser..."

/Sal

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Sep 2009 16:46:36 +0200

> the proposed text is for long term solution...

Even in that case it would be problematic; that's more like a 
requirement when moving from Proposed Standard to Draft Standard.

I think my position is neutral on this, but keep in mind that whatever 
you put into the Charter will be extremely hard to change later on.

BR, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Sep 2009 09:39:45 -0600

> you put into the Charter will be extremely hard to change later on.

It is a nice goal to have any solutions implemented in multiple web
clients, web servers, and intermediaries, but it's not clear to me that
such a goal needs to be in the Charter.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 24 Sep 2009 19:28:31 +0300

right!
maybe the only thing we need in the Charter is something that explicitly 
says
that the long term solution should be suitable for both "generic" and 
Web Browser client.

What I mean is that it should be clear in the Charter the WG will work 
to standardize a generic solution
that can work in all the environments and it is not specific for just one.

Sal

Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkq7ksEACgkQNL8k5A2w/vxAHACglEHmSXQiEjyFkNSvrBKOMXwe
> O48AnAmqkVhPcv0DmgPVkn5OJCwIbnND
> =99IG
> -----END PGP SIGNATURE-----
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Sep 2009 10:31:41 -0600

> that can work in all the environments and it is not specific for just one.

Yes, that wording is better because it doesn't tie us down. :) Now we
just need to say what we mean by "all the environments" (any web browser
or generic HTTP client, any web server, intermediaries, etc.).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Infinity Linden <[email-masked]>
Date: Thu, 24 Sep 2009 11:02:26 -0700

hey peeps. sorry to chime in here a little late, but it's been hectic
for me lately.

i'm watching all this discussion of browsers go by and i felt it's
necessary to chime in and remind everyone that there are a goodly
number of peeps that "use http as a substrate." that is, we use HTTP
to communicate distributed application state to non-browser clients.
the current example i'm most familiar with is the Second Life Viewer,
which will eventually be brought in line with the work we're hoping to
do in VWRAP.

if anyone's interested, we use HTTP for a number of reasons. Most
importantly is the fact that it's nice to not have to reinvent
request-response semantics and that there's a very nice infrastructure
that's been build around delivering HTTP from clients to servers.

so while i'm interested in seeing something that plays nice with
browsers, it's not my primary focus.

but i'm under no illusions that my use case is larger than the browser
use case. i totally get it that the infrastructure i'm layering on top
of was designed (mostly) to deliver HTML to browsers. but i did want
to speak up and make sure that the "using HTTP as a substrate" use
case isn't forgotten.

specifically... there are a few things that are important to me:

* reverse http like semantics. we like to push entire HTTP requests
from the server to the client. this is why we've been working on
RHTTP. this is a little bit different than web sockets, but i would
argue is a very usable feature and if we need both web sockets and
reverse http style semantics, maybe we could layer RHTTP on top of web
sockets somehow?

* multiplexing multiple message streams over a single connection. our
model is to have a bunch of addressable things on the client and a
bunch of services on the server that wants to get info from the
client. we don't want to force the client to open multiple connections
with the server, so we need to be able to address distinct "entities"
or "objects" on the client. we're pretty sure we can do this with
RHTTP. yes, this _could_ be done with web sockets, but we think we can
get some better / more rational behavior out of intermediary systems (
i.e. - caching or security proxies ) if this was a feature of the
protocol instead of the application.

so.. dare i mention BCP 56? i think we all agree it could use some
updating, but MUST it be updated before we can move forward with HyBi
as a substrate?

-cheers
-meadhbh

On Thu, Sep 24, 2009 at 9:31 AM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> iEYEARECAAYFAkq7nuwACgkQNL8k5A2w/vz5fACfV3U7tdbkWsfG1z6IVNouG0X9
> gSUAnizbfxBSrXnHHVYsj3ZGIadjEYW4
> =jIog
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 24 Sep 2009 17:42:21 -0500

> such a goal needs to be in the Charter.

Whatever we do, we are bound by the IETF principle that requires interoperating implementations.  I don't see any need to state a specific implementation goal in the Charter.

That said, if the fruits of the WG are ignored by browser vendors, I'd likely* consider that a failure on the part of the WG.

--Martin

[*] Unless, for instance, the non-browser users really benefit, or clients can use whatever it is without cooperation from browsers.
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 25 Sep 2009 09:31:14 +1000

Infinity Linden wrote:

> number of peeps that "use http as a substrate."

meadhbh,

I completely agree that non browser cases have to be supported.

But I think most of the proposed wordings have covered non browsers:

 "long term solution should also be suitable for clients other than
  Web Browser"

 "the WG will work to standardize a generic solution that can work in
  all the environments and it is not specific for just one"

> reverse http style semantics, maybe we could layer RHTTP on top of web

Have you had a look at the latest BWTP proposal.
  http://bwtp.wikidot.com/main:proposal1

It has a short appendix B suggesting how HTTP can be carried
over BWTP.   This would give both reverse HTTP semantics and
allow out of order responses (on different channels) over the
one TCP/IP connection.

I'd be really interested in your feedback and thoughts on that
proposal.

> protocol instead of the application.

Again, feedback on BWTP welcome, as I think it address this concern
by allowing intermediaries to be first class participants in
bidirectional connections.

> updating, but MUST it be updated before we can move forward with HyBi

I think that an update of BCP 56 is obviously related to the short term
goals of HyBi, but I see that more as an outcome rather than a prerequisite.

cheers