fix mqtt

Signed-off-by: Doug Davis <dug@us.ibm.com>

http-transport-binding.md

@@ -173,7 +173,7 @@ mapping to HTTP headers for those attributes, especially if specific attributes
 need to align with HTTP features or with other specifications that have explicit
 HTTP header bindings. Note that these attributes MUST also still appear in the
 HTTP message as HTTP headers with the `ce-` prefix as noted in
-[HTTP Header Names](#http-header-names).
+[HTTP Header Names](#3131-http-header-names).
 
 ##### 3.1.3.1. HTTP Header Names
 

mqtt-transport-binding.md

@@ -65,9 +65,9 @@ placed into the MQTT PUBLISH message payload section using an
 
 In the _binary_ content mode, the value of the event `data` is placed
 into the MQTT PUBLISH message's payload section as-is, with the
-`datacontenttype` attribute value declaring its media type. All event
-attributes (including `datacontenttype`)are mapped to the MQTT PUBLISH
-message's [properties section][5-publish-properties].
+`datacontenttype` attribute value declaring its media type in the MQTT
+PUBLISH message's [`Content Type`][5-content-type] property; all other
+event attributes are mapped to User Property fields.
 
 ### 1.4. Event Formats
 
@@ -149,8 +149,8 @@ payload of the MQTT PUBLISH message.
 
 #### 3.1.3. Metadata Headers
 
-All [CloudEvents][ce] context attributes, including `datacontenttype`,
-MUST be individually mapped to and from the User Property fields in the MQTT
+All other [CloudEvents][ce] context attributes, including extensions, MUST be
+individually mapped to and from the User Property fields in the MQTT
 PUBLISH message.
 
 CloudEvents extensions that define their own attributes MAY define a secondary

spec.md

@@ -428,8 +428,8 @@ attribute MAY define a secondary serialization where the data is duplicated
 in some other location within the message.
 
 In cases where a secondary serialization is defined, the extension
-specification MUST also state what a receiver of the CloudEvent should do
-is the data differs between those two serialization locations. Additionally,
+specification MUST also state what a receiver of the CloudEvent is to do
+if the data differs between those two serialization locations. Additionally,
 senders need to be prepared for intermediaries, and receivers, to not
 know about their extension and therefore the specialized serialization version
 version will most likely not be processed as a CloudEvent extension attribute.