Hi,

Hmm. mostly OK but I think we have to look ahead.  HTTP/2 will certainly be through the publication pipeline by the time that OCCI 1.2 makes it to publications tatus for review.

Some up to date references:

https://http2.github.io

http://www.ietf.org/blog/2015/02/http2-approved/

http://www.rfc-editor.org/queue2.html#draft-ietf-httpbis-http2

You may also want to look through the FAQ items:

https://http2.github.io/faq/

I think that all that is necessary right now is to take note (as has been stated before by members of this group) that HTTP/2 does not affect the design or basic use of the OCCI specs, and initiate a study to explore the practical use of HTTP/2 with OCCI (1.1. or 1.2).

For the latter, please join the “Cloud Interoperability testbed” project on Chameleon (http://chameleoncloud.org) (project FG-176) and/or the “cacnetworking” project on CloudLab (http://cloudlab.us) if your project has something to do with networking or would be a better fit there. These projects are new, managed by me, and approved specifically to do testing in multiple cloud software environments for interoperability and standards-based software. I would like to encourage the entire OCCI working group, and any other group member of standards efforts in other organizations to join. Accounts are free, the projects are new, and the door is open to participation from this group.

Alan

On Mar 17, 2015, at 11:53 AM, Michel Drescher <michel.drescher@egi.eu> wrote:

Hi Boris, all,

There are two major reasons for being specific about HTTP/1.1 as follows:
1) HTTP/2 is in the making, that is true - but there is no referenceable RFC out there.
2) OCCI Restful makes itself a specific reference to HTTP/1.1 (c.f. GFD.185 reference no. 5) and its serialisation mechanisms.

Regarding the compatibility with HTTP/2, or whether HTTP/2 implementations would be considered eligible to claim conformance.
Both OCCI Restful as well as the profile make references to the HTTP header rendering mechanism defined in HTTP 1.1. But neither imposes any conformance requirement that the HTTP/1.1 protocol itself must be used.
Furthermore, the only situation in which this discussion applies is where both client and server support HTTP/2 - in all other situations, any attempt to initiate a protocol upgrade to HTTP/2 will fail and communications remain at HTTP/1.1 level.

Having said that, HTTP/2 does impose any restrictions or changes on HTTP header rendering, HTTP messages etc. Hence conformity with both OCCI Rendering and the profile are considered as achieved from my point of view.

Cheers,
Michel

P.S.: A corollary implication from this is IMHO that there is no need to upgrade any existing specification, even in the event of HTTP/2 obsoleting HTTP/1.1 (which it states as not being the goal).

On 17 March 2015 at 15:18, Boris Parak <xparak@mail.muni.cz> wrote:
On Tue, Mar 17, 2015 at 3:22 PM, Sill, Alan <alan.sill@ttu.edu> wrote:
> Any particular reason to specify exactly HTTP/1.1? I think that there are many advantages to using HTTP/2 for header compression, possibility to use multiplexed single-connection communications, binary representation, server push responses, etc. It’s backwards compatible so I think we need to allow for more generality.

Good point. There is no specific reason to use HTTP/1.1, aside from it
being referenced in OCCI 1.1 HTTP Rendering spec [1]. If using HTTP/2
doesn't break anything with regard to OCCI 1.1, we can use it.
Otherwise it will have to be included in an updated version of the
profile for OCCI 1.2. In any case, it would be an encouragement, not a
requirement (for practical reasons).

Michel, is this correct?

[1] https://www.ogf.org/documents/GFD.185.pdf

>
> I started a discussion on tis on another thread, but am holding off asking for anything specific until we can try it out.
>
> Alan

Boris

>> On Mar 17, 2015, at 7:21 AM, Boris Parak <xparak@mail.muni.cz> wrote:
>>
>> Hello everyone,
>>
>> I have here, for your consideration, one of the first "formal" outputs
>> of EGI FedCloud's work with OCCI -- The OCCI Resource Template
>> Profile. We would very much like to hear your opinions, comments
>> and/or suggestions.
>>
>> After this (brief, hopefully) internal discussion phase, we would like
>> to push for a public comment phase as soon as possible.
>>
>> Thank you!
>>
>> Cheers, Boris
>> ---
>> CESNET / EGI FedCloud
>> <OCCI Resource template profile v6.docx><OCCI Resource template profile v6.pdf><OCCI Resource template profile v6.rtf>_______________________________________________
>> occi-wg mailing list
>> occi-wg@ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg
>



--
Stichting European Grid Initiative (EGI.eu)
http://www.egi.eu
Mobile:+31 (0)6 303 726 55
Skype: michel.drescher.egi

Entropy isn't what it used to be...