[OASIS Issue Tracker] (AMQP-130) Clarify Transfer message-format field description

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Robert Gemmell commented on AMQP-130:
-------------------------------------

Someone involved in writing the spec might know better, but I'd guess that is in part due to the separation/layering of the spec. The transport layer bits don't really know about the messaging layer bits, so the reason the message format doesn't have a default (<field name="message-format" type="message-format"/>) may simply be because the spec-defined message format isn't covered by the transport section but rather the messaging section later on. As you note zero might have been an obvious default if there was one, and I'd say that even regardless of the structure when thinking that all messages really need to have a format.

Given the lack of default format, the main reason I can see to stipulate it as mandatory on the first transfer of a multi-frame delivery is so that you can always tell what format of message it is should you need/want to inspect the content in any way before receiving a subsequent frame (or even the complete message) that did give a value. Given the note that it is an error to use a different format on continuation frames than the first, that would already mean you would have to set any non-default value on the first frame if there had been a default. I guess the main argument for a default is that things commonly wont use a different message format (though I do know of one that does) so a default could be more efficient much of the time, though that isn't always going to be the case since if any later field is defined in the transfer frame there would still have to be a 1 byte null encoding for omission in place of the 1 byte zero encoding for the spec defined format. In some ways it was probably just simpler making all these cases consistent by saying you must set a format.

I would say that it currently follows that you do need to set it on a single transfer delivery, though I think you can already take that meaning from "and can only be omitted for continuation transfers" if considering the "and" to mean two statements of when it must be set and can be omitted rather than e.g that the sentence only applies to multi-frame deliveries. I'd definitely agree it could be stated more explicitly to avoid any need to wonder which it actually is :)

> Clarify Transfer message-format field description
> -------------------------------------------------
>
>                 Key: AMQP-130
>                 URL: https://issues.oasis-open.org/browse/AMQP-130
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Improvement
>          Components: Transport
>            Reporter: Lorenz Quack
>              Labels: Clarification
>
> The AMQP specification states in section 2.7.5 [1] about the message-format field of the Transfer performative:
> This field MUST be specified for the first transfer of a multi-transfer message and can only be omitted for continuation transfers. It is an error if the message-format on a continuation transfer differs from the message-format on the first transfer of a delivery.
> There are two things I would like the specification to be more explicit about:
> * Whether the field is required on single transfer deliveries (see also AMQP-128).
> * How to handle the error condition. Do we reject the message? Detach the Link? End the Session? Close the Connection? What ErrorCondition should be used?
> [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-transfer



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