Tracking Ticket: Known deviations

[ldeichmann]

• WSDL fetching does not support all methods (mdpws:R0010, mdpws:R0011, mdpws:R0014)
• wsp:PolicyURIs checking is not supported (mdpws:R0010, mdpws:R0011)
• ArchiveService messages are unsupported (mdpws:R0006)
• Multipart/Related Content-Type is unsupported (mdpws:R0006)
• SDC Glue Annex B should be tested, but doesn't have a requirement attached. Maybe BICEPS:R0062 etc. which describe required and optional services are the correct spot?
• unconditional compliance with RFC 2616 is currently NOT checked, which means no adherence to the following:

  • Any HTTP/1.1 message containing an entity-body SHOULD include a
    Content-Type header field defining the media type of that body. If
    and only if the media type is not given by a Content-Type field, the
    recipient MAY attempt to guess the media type via inspection of its
    content and/or the name extension(s) of the URI used to identify the
    resource. If the media type remains unknown, the recipient SHOULD
    treat it as type "application/octet-stream".

• BICEPS R0105 includes unicode code points, that are not UTF-8 compatible
  • Tested replacement:

    • A HANDLE SHALL only consist of characters that match ASCII character codes in the range of [0x21, 0x7E].

• MDPWS R0007 is wrong, because UTF-8 is not  a binary -> binary encoding, but unicode -> binary, a TEXT SOAP ENVELOPE is by definition already binary encoded
  • Assumed replacement:

    • SOAP ENVELOPEs SHALL be encoded by using UTF-8.

• Containment Tree definition is contradictory to other definitions and BICEPS R0098 is not global, see:
  • https://sourceforge.net/p/opensdc/ieee11073-10207/175/
  • https://sourceforge.net/p/opensdc/ieee11073-10207/174/
  • Tested replacement:

    • If a SERVICE PROVIDER inserts an ELEMENT with a HANDLE that has been used in a previous MDIB version of the same MDIB sequence, this ELEMENT SHALL be of the same XML Schema datatype as every ELEMENT that previously carried the HANDLE.

⚠️: As stated in the README.md, when a feature is unsupported, SDCcc cannot be applied to devices using it as this may cause false positives or false negatives in some test cases. In order to minimize this risk, SDCcc's test cases are designed to fail when they notice that the device uses unsupported features. This has no effect when applying it to devices using supported features only, but significantly reduces the risk induced by unsupported features as the Test engineer will surely notice that something is wrong.