[Telepathy-commits] [telepathy-spec/master] DeliveryReporting: move enums and DeliveryReportingSupport to Messages
Simon McVittie
simon.mcvittie at collabora.co.uk
Tue Oct 28 10:09:29 PDT 2008
---
spec/Channel_Interface_Delivery_Reporting.xml | 98 -------------------------
spec/Channel_Interface_Messages.xml | 98 +++++++++++++++++++++++++
2 files changed, 98 insertions(+), 98 deletions(-)
diff --git a/spec/Channel_Interface_Delivery_Reporting.xml b/spec/Channel_Interface_Delivery_Reporting.xml
index 910fc72..ee4785e 100644
--- a/spec/Channel_Interface_Delivery_Reporting.xml
+++ b/spec/Channel_Interface_Delivery_Reporting.xml
@@ -254,104 +254,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</dl>
</tp:docstring>
- <tp:enum name="Delivery_Status" value-prefix="Delivery_Status" type="u">
- <tp:docstring>
- <p>The status of a message as indicated by a delivery report.</p>
-
- <p>If this enum is extended in future specifications, this should
- only be to add new, non-overlapping conditions (i.e. all failures
- should still be signalled as either Temporarily_Failed
- or Permanently_Failed). If additional detail is required (e.g.
- distinguishing between the various types of permanent failure) this
- will be done using additional keys in the Message_Part.</p>
- </tp:docstring>
-
- <tp:enumvalue suffix="Unknown" value="0">
- <tp:docstring>
- The message's disposition is unknown.
- Clients SHOULD consider all messages to have status
- Delivery_Status_Unknown unless otherwise specified; connection
- managers SHOULD NOT signal this delivery status explicitly.
- </tp:docstring>
- </tp:enumvalue>
-
- <tp:enumvalue suffix="Delivered" value="1">
- <tp:docstring>
- The message has been delivered to the intended recipient.
- </tp:docstring>
- </tp:enumvalue>
-
- <tp:enumvalue suffix="Temporarily_Failed" value="2">
- <tp:docstring>
- Delivery of the message has failed. Clients SHOULD notify the user,
- but MAY automatically try sending another copy of the message.
-
- <tp:rationale>
- Similar to errors with type="wait" in XMPP; analogous to
- 4xx errors in SMTP.
- </tp:rationale>
- </tp:docstring>
- </tp:enumvalue>
-
- <tp:enumvalue suffix="Permanently_Failed" value="3">
- <tp:docstring>
- Delivery of the message has failed. Clients SHOULD NOT try again
- unless by specific user action. If the user does not modify the
- message or alter configuration before re-sending, this error is
- likely to happen again.
-
- <tp:rationale>
- Similar to errors with type="cancel", type="modify"
- or type="auth" in XMPP; analogous to 5xx errors in SMTP.
- </tp:rationale>
- </tp:docstring>
- </tp:enumvalue>
- </tp:enum>
-
- <tp:flags name="Delivery_Reporting_Support_Flags"
- value-prefix="Delivery_Reporting_Support_Flag" type="u">
- <tp:docstring>
- Flags indicating the level of support for delivery reporting on this
- channel. Any future flags added to this set will conform to the
- convention that the presence of an extra flag implies that
- more operations will succeed.
- </tp:docstring>
-
- <tp:flag suffix="Receive_Failures" value="1">
- <tp:docstring>
- Clients MAY expect to receive negative delivery reports if
- Message_Sending_Flag_Report_Delivery is specified when sending.
-
- <tp:rationale>
- If senders want delivery reports, they should ask for them.
- If they don't want delivery reports, they can just ignore them,
- so there's no need to have capability discovery for what will
- happen if a delivery report isn't requested.
- </tp:rationale>
- </tp:docstring>
- </tp:flag>
-
- <tp:flag suffix="Receive_Successes" value="2">
- <tp:docstring>
- Clients MAY expect to receive positive delivery reports if
- Message_Sending_Flag_Report_Delivery is specified when sending.
-
- <tp:rationale>
- Same rationale as Receive_Failures.
- </tp:rationale>
- </tp:docstring>
- </tp:flag>
-
- </tp:flags>
-
- <property name="DeliveryReportingSupport" access="read"
- tp:type="Delivery_Reporting_Support_Flags" type="u"
- tp:name-for-bindings="Delivery_Reporting_Support">
- <tp:docstring>
- A bitfield indicating features supported by this channel.
- </tp:docstring>
- </property>
-
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml
index e5e3109..4585bc0 100644
--- a/spec/Channel_Interface_Messages.xml
+++ b/spec/Channel_Interface_Messages.xml
@@ -708,6 +708,104 @@ USA.</p>
</arg>
</signal>
+ <tp:enum name="Delivery_Status" value-prefix="Delivery_Status" type="u">
+ <tp:docstring>
+ <p>The status of a message as indicated by a delivery report.</p>
+
+ <p>If this enum is extended in future specifications, this should
+ only be to add new, non-overlapping conditions (i.e. all failures
+ should still be signalled as either Temporarily_Failed
+ or Permanently_Failed). If additional detail is required (e.g.
+ distinguishing between the various types of permanent failure) this
+ will be done using additional keys in the Message_Part.</p>
+ </tp:docstring>
+
+ <tp:enumvalue suffix="Unknown" value="0">
+ <tp:docstring>
+ The message's disposition is unknown.
+ Clients SHOULD consider all messages to have status
+ Delivery_Status_Unknown unless otherwise specified; connection
+ managers SHOULD NOT signal this delivery status explicitly.
+ </tp:docstring>
+ </tp:enumvalue>
+
+ <tp:enumvalue suffix="Delivered" value="1">
+ <tp:docstring>
+ The message has been delivered to the intended recipient.
+ </tp:docstring>
+ </tp:enumvalue>
+
+ <tp:enumvalue suffix="Temporarily_Failed" value="2">
+ <tp:docstring>
+ Delivery of the message has failed. Clients SHOULD notify the user,
+ but MAY automatically try sending another copy of the message.
+
+ <tp:rationale>
+ Similar to errors with type="wait" in XMPP; analogous to
+ 4xx errors in SMTP.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:enumvalue>
+
+ <tp:enumvalue suffix="Permanently_Failed" value="3">
+ <tp:docstring>
+ Delivery of the message has failed. Clients SHOULD NOT try again
+ unless by specific user action. If the user does not modify the
+ message or alter configuration before re-sending, this error is
+ likely to happen again.
+
+ <tp:rationale>
+ Similar to errors with type="cancel", type="modify"
+ or type="auth" in XMPP; analogous to 5xx errors in SMTP.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:enumvalue>
+ </tp:enum>
+
+ <tp:flags name="Delivery_Reporting_Support_Flags"
+ value-prefix="Delivery_Reporting_Support_Flag" type="u">
+ <tp:docstring>
+ Flags indicating the level of support for delivery reporting on this
+ channel. Any future flags added to this set will conform to the
+ convention that the presence of an extra flag implies that
+ more operations will succeed.
+ </tp:docstring>
+
+ <tp:flag suffix="Receive_Failures" value="1">
+ <tp:docstring>
+ Clients MAY expect to receive negative delivery reports if
+ Message_Sending_Flag_Report_Delivery is specified when sending.
+
+ <tp:rationale>
+ If senders want delivery reports, they should ask for them.
+ If they don't want delivery reports, they can just ignore them,
+ so there's no need to have capability discovery for what will
+ happen if a delivery report isn't requested.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:flag>
+
+ <tp:flag suffix="Receive_Successes" value="2">
+ <tp:docstring>
+ Clients MAY expect to receive positive delivery reports if
+ Message_Sending_Flag_Report_Delivery is specified when sending.
+
+ <tp:rationale>
+ Same rationale as Receive_Failures.
+ </tp:rationale>
+ </tp:docstring>
+ </tp:flag>
+
+ </tp:flags>
+
+ <property name="DeliveryReportingSupport" access="read"
+ tp:type="Delivery_Reporting_Support_Flags" type="u"
+ tp:name-for-bindings="Delivery_Reporting_Support">
+ <tp:docstring>
+ A bitfield indicating features supported by this channel.
+ </tp:docstring>
+ </property>
+
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
--
1.5.6.5
More information about the Telepathy-commits
mailing list