OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp-bindmap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (AMQPBINDMAP-38) Grammer, sect 1, 2nd bullet


    [ https://issues.oasis-open.org/browse/AMQPBINDMAP-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62171#comment-62171 ] 

Stefan Hagen edited comment on AMQPBINDMAP-38 at 3/27/16 7:44 PM:
------------------------------------------------------------------

Amended Proposal:

Replace:
----------------------------------------------------------------------------------------
h4. 1 Introduction

This specification describes how the WebSocket protocol can be used as a transport for AMQP 1.0 
protocol traffic. It is applicable for two main scenarios:

* Firewall traversal. Since Websocket connection establishment is implemented as standard HTTP traffic using the default ports (80 and 443), it is often able to pass through network security devices without requiring special configuration or opening of additional ports. In this scenario, the AMQP communication can be between arbitrary AMQP peers, e.g., between an application using an AMQP client library and a message broker.

* Browser-based messaging. Since many Web browsers have built-in support for the WebSocket protocol, then this binding can be used to enable AMQP messaging through to the browser 
thereby enable a broad range of browser-based messaging scenarios.

An AMQP 1.0 protocol session begins with the protocol version negotiation, including the establishment of layered security layers if required. Once this is complete, the session continues with the exchange of AMQP frames that control the operation of the protocol and transport the business messages between the communicating peers.

The remainder of this specification describes how these concepts are mapped to a WebSocket transport.

----------------------------------------------------------------------------------------

With:
----------------------------------------------------------------------------------------
h4. 1 Introduction

This document specifies a WebSocket subprotocol as transport for AMQP 1.0 protocol traffic.  It is applicable for two main scenarios:

* Firewall traversal. WebSocket connection establishment is through HTTP traffic using the default ports (80 and 443). Many network security devices support these ports and this traffic type. That enables arbitrary AMQP peer communication. Sample: An application using an AMQP client library connecting to a message broker.

* Browser-based messaging. Modern Web browsers include a WebSocket client stack, thus support direct AMQP messaging. This enables a broad range of browser-based messaging scenarios.

Two peers begin a AMQP 1.0 protocol session with the negotiation of the protocol version. If required, this negotiation includes the establishment of layered security layers. Upon completion the session continues with the exchange of AMQP frames. For one these control the operation of the protocol. For two they transport the business messages between the communicating peers.

The rest of this specification describes how these concepts map to a WebSocket transport.
----------------------------------------------------------------------------------------

Rationale: Easier to read (caveat: I am not a native English speaker), more to the point. I think naming this "binding" a "subprotocol" is more clear to me, but I may well be wrong. Please advise.


was (Author: sdrees):
Amended Proposal:

Replace:
{code}
1 Introduction

This specification describes how the WebSocket protocol can be used as a transport for AMQP 1.0 
protocol traffic. It is applicable for two main scenarios:

* Firewall traversal. Since Websocket connection establishment is implemented as standard HTTP traffic using the default ports (80 and 443), it is often able to pass through network security devices without requiring special configuration or opening of additional ports. In this scenario, the AMQP communication can be between arbitrary AMQP peers, e.g., between an application using an AMQP client library and a message broker.

* Browser-based messaging. Since many Web browsers have built-in support for the WebSocket protocol, then this binding can be used to enable AMQP messaging through to the browser 
thereby enable a broad range of browser-based messaging scenarios.

An AMQP 1.0 protocol session begins with the protocol version negotiation, including the establishment of layered security layers if required. Once this is complete, the session continues with the exchange of AMQP frames that control the operation of the protocol and transport the business messages between the communicating peers.

The remainder of this specification describes how these concepts are mapped to a WebSocket transport.

{code}

With:
{code}
1 Introduction

This document specifies a WebSocket subprotocol as transport for AMQP 1.0 protocol traffic.  It is applicable for two main scenarios:

* Firewall traversal. WebSocket connection establishment is through HTTP traffic using the default ports (80 and 443). Many network security devices support these ports and this traffic type. That enables arbitrary AMQP peer communication. Sample: An application using an AMQP client library connecting to a message broker.

* Browser-based messaging. Modern Web browsers include a WebSocket client stack, thus support direct AMQP messaging. This enables a broad range of browser-based messaging scenarios.

Two peers begin a AMQP 1.0 protocol session with the negotiation of the protocol version. If required, this negotiation includes the establishment of layered security layers. Upon completion the session continues with the exchange of AMQP frames. For one these control the operation of the protocol. For two they transport the business messages between the communicating peers.

The rest of this specification describes how these concepts map to a WebSocket transport.
{code}

Rationale: Easier to read (caveat: I am not a native English speaker), more to the point. I think naming this "binding" a "subprotocol" is more clear to me, but I may well be wrong. Please advise.

> Grammer, sect 1, 2nd bullet
> ---------------------------
>
>                 Key: AMQPBINDMAP-38
>                 URL: https://issues.oasis-open.org/browse/AMQPBINDMAP-38
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC
>          Issue Type: Bug
>          Components: Websockets Binding
>    Affects Versions: wd08
>            Reporter: Steve Huston
>            Assignee: John Fallows
>            Priority: Trivial
>
> "Browser-based messaging. Since many Web browsers have built-in support for the WebSocket protocol, then this binding can be used to enable AMQP messaging through to the browser thereby enable a broad range of browser-based messaging scenarios."
> remove "then", change 2nd "enable" to "enabling"
> change to:
> "Browser-based messaging. Since many Web browsers have built-in support for the WebSocket protocol, this binding can be used to enable AMQP messaging through to the browser thereby enabling a broad range of browser-based messaging scenarios."



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]