← Prev in month ← Prev in thread
Next in thread → Next in month →

A few more SMP comments

From
Pim van der Eijk <>
Date
2017-05-22T07:47:12+00:00
ID
Thread
A few more SMP comments
Hi,

    
I've had to look at the SMP spec and schema last week,  and have
      a few more comments.

    
1)  The ebCore Party Identifier format is defined in section 2.7
      of [PARTYIDTYPE] and has the pattern urn:oasis:tc:ebcore:partyid-type:catalog-identifier:scheme-incatalog:scheme-specific-identifier
      i.e. the scheme-incatalog and scheme-specific-identifier
      are separated by a single colon.  Section 2.4.5.3 of the SMP
      specification has example party identifiers in ebCore Party ID and
      PEPPOL UPIS format.  The non-normative ebCore Party ID example
      given, urn:oasis:names:tc:ebcore:partyid-type:iso6523:0010::5798000000001,
      is incorrect, it has two colons.

    
2)  Another comment on that example is that it is claimed that
      the UPIS and ebCore identifiers are "
      
      the same non-normative example".  But the PEPPOL code "0010", for
      GS1 Global Location Numbers,  is not the same as the ISO 6523 code
      "0010".  In ISO 6523, code “0010” is not a code for GLN
      identifiers but for “Organizational Identifiers for Structured
      Names under ISO 9541 Part 2” from the “Association for Font
      Information Interchange: AFII”.  The ISO 6523 code value for GLNs
      is “0088”.

    

    
3) The specification has a normative reference to XML Signature
      1.1 (2013),  but the SMP scheme imports the schema of XML
      Signature 1.0 (2001).  A valid driver for XML Signature 1.1 is
      included in ebCore Agreement Update
http://docs.oasis-open.org/ebcore/ebcore-au/v1.0/cs01/schema/xmldsig1-schema.xsd.
      (The schema driver at the W3C site is actually not valid).

    

    
4) There are "RecipientIdentifier" and "SenderIdentifier"
      elements in the SMP schema that are not defined in the
      specification.   They are also not used in any of the defined
      content models in the schema, i.e. the cannot occur anywhere at
      any level in a ServiceGroup or (Signed)
      
      ServiceMetadata.

    
Kind Regards,

    
Pim
← Prev in month ← Prev in thread
Next in thread → Next in month →