Re: [ogpx] Transport independence (Re: Next Steps for OGPX WG Charter)

I observe that the Shoutcast audio streaming service uses HTTP.  They 
initiate the connection with the headers and them leave it open for a 
loooong time sending data packets.  Similarly XMPP sends an XML 
'document' that takes HOURS to send, very slowly, one stanza at a time;  
in fact both ways at once.

With those examples I see no problem in using HTTP(s) headers to 
describe the desired service endpoint (as Dave Crocker pointed out) and 
maybe encoding format, for a connection that stays open for a long 
time.  I do think an exchange of HTTP headers per operation would be 
huge overkill for all but bulk transfers:  textures, sounds, etc.

This meets the needs for both supra-transport addressing and wide 
network reach, without imposing unreasonable end-to-end round-trip 
delays blocking the channel.

Independent services, such as messaging, asset downloading, locality 
information, might even use separate connections, to different 
endpoints, depending how capabilities are managed within a given virtual 
world administrative domain.

-Mo

Rob Lanphier wrote:
> On 08/01/2009 06:54 PM, Dave CROCKER wrote:
>   
>> Joshua Bell wrote:
>>     
>>> 12. Clarify the charter that we're explicitly targetting HTTP as the
>>> default transport.
>>>
>>> A concern was raised that reusing HTTP will lead to unnecessary and
>>> tight coupling with that protocol's capabilities and semantics; a
>>> suggestion was made that if we wish to state that the protocols will
>>> be transport-neutral, the WG will investigate at least one other
>>> transport. Should we just target HTTP, or make the effort?
>>>       
>> If transport-independence is claimed, the claim won't really be
>> meaningful unless at least two different transport mappings are provided.
>>     
>
> For the claim to be watertight, two different transport mappings would
> need to be provided. However, it's still possible to make a meaningful
> claim of transport-independence mainly by making sure that:
> 1. The transport requirements (and non-requirements) are clearly specified
> 2. Everyone remains vigilant about ensuring that transport expectations
> are specified in the requirements
>
> Unless there's a great deal of interest from implementors to implement
> some other transport, it seems silly to waste the effort specifying
> another transport in the name of making a watertight claim of transport
> independence.
>
> Rob
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>   