3GPP TSG-T WG2 SWG3#11
Seattle, WA, USA
29th April – 2nd May 2002	T2M020146	

Agenda Item:	MM7 Stage 3

Source:	Logica

Title:	Reply from Logica to Comverse’s Reply to Points raised by Ericsson, Logica, and Nokia in T2M020145.

Document for:	Discussion

The remainder of this document contains Logica responses to Comverse’s issues raised in T2M020145. Logica comments are contained in bold/italics
___________________________________________________________________________

Agenda Item:	MM7 Stage 3

Source:	Comverse

Title:	Reply to Points raised by Ericsson, Logica, and Nokia 

Document for:	Discussion

___________________________________________________________________________

1.	Introduction
After submitting a revised edition of the MM7 Stage 3 proposal comments were received from the following companies – Materna, Ericsson, Logica, and Nokia.  Most of these comments were directly related to the text of the Comverse proposal that was submitted in document TM020122.  Nokia proposed a totally separate MM7 Stage 3 but in many aspects very similar to the Comverse proposal.
In the following sections I will try to point out the main differences that were proposed by these “counter-proposals”.  It should be noted that Materna’s comments were replied to in a previous email message.
2.	Ericsson’s Comments
The major comment, in addition to various editorial corrections – that will be addressed below, was that the error handling should revert to the general guidelines that were proposed at T2#16.  This essentially means that 
•	XML (i.e. SOAP) parsing errors should be treated as SOAP-faults, generating an HTTP error and SOAP envelope that contains a Fault element that describes the error in three sub-elements.
•	Application errors are described in the normal status response message.  Ericsson suggests that there should be only the four error classes that were described in the previous version of the proposal.
In our opinion, the suggestion of returning to the use of SOAP-faults is acceptable, and certainly the use of the normal response message to return the error status was the intention.  What is defined in the proposed (TM020122) is a generic response message type that is used as the basis for all of the response messages.  It is very similar to the MM7_RS_Error.RES, however it was not intended to be the same message.
As to the error codes, it is our opinion that there is a need to differentiate between the cases when the MMS Relay/Server is acting as the server and the cases where the VASP is the server and therefore, we have proposed two sets of Client and Server error classes.  The other classes that are proposed may be covered by the SOAP-faults that we concede may be more appropriate than using the generic error responses.
The editorial comments that were made by Ericsson are, for the most part valid, we only question the following instances:
•	Section 8.7.8.1 third bullet – we feel that it is important that 3GPP publish the schema that will be defined for MM7.
•	Section 8.7.8.1.1 – the corrected text that reads “The content will have two MIME headers such as Content-Type and Content-ID…” we do not understand the use of “such as” and feel that these are the two headers that should be used and not examples.  Therefore, we feel that the statement should read “The content shall be described by two MIME headers – Content-Type and Content-ID…”
•	Section 8.7.8.1.2 – these comments are not fully clear to us.  The additional sentence that was added to the first paragraph makes the first sentence of the second paragraph redundant!  This second paragraph was added mainly to state that the specification cannot dictate authentication methods to the VASP.
In summary, Comverse is willing to revise the proposal for MM7 Stage 3 to reflect the corrections made by Ericsson with the exception of those that are pointed out in this section.

3.	LOGICA COMMENTS
Logica has reworked the proposal and the proposed schema.  Most of these changes derive from certain design principles that Logica suggests that are slightly different from those that were proposed in our revised proposal (a great deal of the revision was made in light of the design principles proposed by Logica!).  The points of contention seem to be:
Logica proposes to base the schema on a SOAP 1.2 schema “that can be used to generate SOAP 1.1 compatible messages”.  When in fact, the schema proposed by both Comverse and Logica are mainly based on basic XML definitions rather than SOAP
Logica understands that the proposal to protocol on SOAP 1.2 is contentious and agrees that SOAP 1.1 will be used. However, none of our proposed changes relate to the use of SOAP 1.2. Some confusion may have been caused by our comment that the SOAP 1.1 schema is based on the SOAP 1.2 schema. This is literally the case ! (see the URL http://schemas.xmlsoap.org/soap/envelope/). The background is as follows
a)	There is no W3C SOAP 1.1 schema. SOAP 1.1 is published as a note by W3C and they reference the external URL http://schemas.xmlsoap.org/soap/envelope/
b)	The original schema at this location was based on a working draft of the W3C schema specification and was not compatible with the final specification
c)	A new SOAP 1.1 schema is now available at this URL. It is actually based on the W3C SOAP 1.2 schema.
d)	The new schema, while compatible with the W3C schema specification, is not a complete schema for SOAP 1.1. In particular, it does not define the Fault element used in SOAP 1.1 only the Fault datatype. This means that MM7 will either have to define this element itself (not a major problem) or else try to get the SOAP 1.1 schema updated.
In light of this confused history, Logica considers it best not to state that the MM7 schema is based on any other schema but rather that it uses a particular schema (schemas.xmlsoap.org/soap/envelope). This is in any case a more correct statement of the relationship between MM7 and SOAP.
The MessageType element should not be defined as a separate element.  The Comverse proposal specifies this as part of the envelope header to allow for pre-processing by intermediate SOAP nodes.
Intermediate nodes cannot pre-process SOAP Headers. Each SOAP node must remove any headers it processes from the message before forwarding the message (see SOAP 1.1 chapter 2: SOAP Message Exchange Mode;). Consequently, Message type is not required..
•	Logica presents a slightly different VASP addressing resolution method from the one that was agreed as part of Stage 2 (as proposed by Nokia).  Logica suggests to separate the VASP MM1 address from the VASP ID and VAS ID and define the MM1 address as a “Sender” element in the submission body, while the VASP ID and VAS ID in the envelope Header for authentication purposes.
To clarify our understanding – the VASP may supply any one (or two) of the following addresses – VASP ID, VAS ID, or its MM1 address – and the MMS Relay/Server is responsible to translate this to the MM1 address that will be presented to the end-user in the MM1_Retrieve as defined in Stage 2 using the information in the VASP Profile.
Logica’s proposal represents our understanding of Nokia’s stage 2 proposal. Namely, that addressing can be used to identify a VASPs to the MMSC and/or to identify an application to the end-user. When the address is supplied in the Header it is used for service authentication and optionally for provision to the end-user. When the address is supplied in the body it is intended purely for the end-user and some alternate service authentication mechanism must be used. We believe this approach is necessary to ensure that stage 3 is fully compliant with the stage 2 specification.
•	Logica specifies that error-codes should be Strings (as opposed to numeric) and should not be extensible.  While this is the standard for SOAP Faults, it is our opinion that numeric error codes would be more appropriate – for processing by external processors, e.g. billing systems, address books.  In addition, certain implementations may want to extend the set of error codes for special VAS applications.
The error codes proposed are extensible in the usual SOAP 1.1. fashion: by adding extra qualifiers to the standard codes. 
Interfacing of  protocol error codes with any external processors is outside the scope of this specification while interfacing with SOAP is very clearly within the scope of this specification.
In addition to these, there is a list of 19 changes that Logica proposes to make to the XML schema that are listed in the introduction to the Annex and reflected in the tables that specify the mappings of the Information Elements to the XML-elements.  In response to these – Comverse is willing to accept the following items – 1, 2, 3, 4 (although unclear where this was necessary), 9 &10 (with slight modification), 13 (with a small reservation), 17, 18.  We have the following comments concerning the other points:
•	Point 5:  There is a need to differentiate between the use of the VASPHeader and RSHeader in order to require the information in the different message-types.  We also feel that the MessageType should appear in the Header elements to allow pre-processing of the message according to its type (this is for forward compatibility).
Needs more clarification. In particular no formal mechanism to restrict information anyway (just because VASP header is used does not mean that body will actually contain VASP-specific elements. Implementations will have to check this manually.
Also, not clear who will need what information. For example a VASP may implement several VASPs on the same URL. But the current proposal does not provide a VAS id in the RS header.
•	Points 6, 7, & 11 and 14: It is unclear what the split into a Header (note that this terminology is confusing with the envelope header and the included XML schema will not parse properly as a result of the multiple Header element definitions!) and Body adds to the clarity of the specification.  In addition the split seems to be arbitrary – why is the Subject not part of the header (most email clients put the Subject line in the header!) and why is the messageClass (point 12) associated with the Content and not part of the header?  Anyway if we assume that the actual content is added as a SOAP Attachment and the Content element is merely a link to the attachment – there is no point to this split!
Main reason is to allow for future expansion. Perhaps SubmitHeader or MMHeader would be better. In any case, best to separate user-visible information from protocol details
•	Point 8:  This is not critical, but why use a different name from what is used in MM1, MM4 and IETF?
On this interface at least, the use of “date” is ambiguous. It could mean submission time or delivery time and for the avoidance of doubt this is best made clear in the specification. 
Additionally, XML elements are frequently parsed automatically and these names will migrate from the specification space, where their meaning can be explained by surrounding text, into the implementation space, where such contextual information is not directly accessible. For this reason, it is much more important in an XML specification that an element  name has one unambiguous meaning. 
•	Points 9 & 10:  We accept the suggestion of defining the Delivery options with the sub-element of ReplyCharging.  We suggest that the expiry date be added as an additional sub-element.
•	Point 12: MessageClass should be an element of the submission – it certainly is not directly related to the content but rather to the message as a whole
•	Point 13: Acceptable, with a small question – if the choice taken is the Fault then the definition of some of the extensions may not be possible.  Is there a way to restrict the extensions to a particular choice in the GenericResponse definition?
Logica believes there is a need for this, The Choice is Success or Warning. Both cases indicate at least partial success and consequently all extensions are possible. Note that a request failure is not defined by these elements and is incompatible with them, failure is indicated by the presence of a SOAP fault element. For completeness, we could possibly have a separate ErrorResponse element. This would be defined as empty and non-extensible (final). 
•	Points 15, 16:  These call for changes in the Stage 2 definition and should be addressed at that level.
Logica does not believe that these changes represent clear protocol implementation decisions that are compatible with the staqe 2 definition. Stage 2 defines abstract elements that are mapped onto concrete elements in stage 3. The detail of this mapping is properly a matter for the stage 3 specification.
In particular, reply charging identity is mapped onto two XML elements MessageId and an optional ReplyPaidBySender element. The fact that XML element MessageId implements two stage 2 fields is an implementation detail. It reduces the scope for ambiguity in the specification and constrains the use of linked-id in the submit request to valid delivered message identifiers. This constraint provides clear implementation advantages as there is now only one valid messageid for every message.
Note: may also be necessary to specify the ReplyPaidBySender element with all of the options defined for submission (i.e. Reply-Deadline, Reply-Charging-Size) as the application needs to know the constraints on the reply message as well)

•	Point 19:  Not very clear from the XML schema when this type is used, and more importantly when it is not used!!
4.	Nokia’s Proposal
Nokia proposes a totally new suggestion – both a design principles document and a CR that diverges greatly from any that have been proposed or discussed until now within the group.  It may be possible to question why this proposal was presented at the last possible moment when the previous design principles document has been available since Feb and previous versions of the Comverse proposal have been available since Dec – but these are not really relevant questions.
Nokia’s proposal may seem greatly divergent at first glance, but after examination it can be shown that the divergence centers around the following main principles:
•	Nokia suggests using a non-SOAP XML schema that just uses the “principles of SOAP structure” rather than use SOAP grammar this leads to SOAP-like message schema.
•	Nokia uses a structure in which everything is in the SOAP-like body with no header.
•	Nokia tries to tie as many of the Information Elements as attributes of other elements as possible!  This leads to some suggestions that we feel are acceptable and others that seem a bit constrained and cause inconsistencies in the general specification.
•	Nokia uses the RS_Error and VASP_Error messages in place of SOAP Faults – that they avoid as a result of the first point.  This should lead to the objection raised by Ericsson from the Comverse proposal – that it deviates from the Stage 2 definition.
Comverse would like to accept some of the suggestions made by Nokia while maintaining the SOAP grammar for MM7 and trying to comply with the suggestions made by Ericsson and Logica – These include – 
•	Changing the definition of the Recipients element to support the different address types (this was also suggested by Logica) and not to support the To, Cc, and Bcc elements for message submission.  This latter point is quite sensible for the use-case of a VASP submitting a message to a mass distribution list.  In addition, we feel (after reconsideration) that the recipient list should be treated as a BCC list by the Relay/Server.
•	We feel that while there are certain problems with the attribute sets suggested by Nokia – and one appears in the Submit example that is included in the Nokia CR, i.e. even though the charging attribute is “false” the chargingSize is still there!!  We think that our agreement to the Logica suggestion (Points 9 & 10 above) should be in keeping with the Nokia suggestion.
•	It should be noted that the ServiceCode as defined in Stage 2 is “implementation specific” and therefore cannot be assumed to be numeric as seems to be understood by Nokia and therefore (according to Nokia’s design principles) should not be an attribute but rather an XML element!
5.	Conclusion
Comverse is willing to prepare a new revised version of the Stage 3 definition to present on Monday as the basis for the discussions, based on the comments and the acceptable points that were raised, if this will help us reach a consensus in a timely fashion.  If, however, we do not accept such a revision as the basis, it is our feeling that we will not reach such a consensus by Thursday afternoon!!