OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ebxml-iic] RE: EAN.UCC TRP guidelines


I have read through the EAN.UCC ebXML TRP Implementation Guidelines
document, and have these comments.

Clearly the authors' intent was to provide details that are specific
to the EAN.UCC standards, to enable deployments that are interoperable
within that user community.  As such, I find little in the way of
general implementation or deployment guidelines that would be
applicable outside the scope of EAN.UCC.

A software developer would be well advised to consider such a set of
guidelines as a "typical" use case that the implementation should be
able to support, since the recommendations are all within the bounds
of a compliant implementation.

Here is a summary, by section, of the specific recommendations
proposed in the document:

3.1 Minimally conformant implementations (containing all Core
Functionality) are "good enough".  Additional features from Part II
are recommended.

3.2.1 Additional packaging for Payload Container is described.
(EAN.UCC-specific; not applicable in general.)

3.2.2 UTF-8 charset/encoding is required.

3.3.1.1 Recommends PartyId type to be selected from GLN (preferred) or
DUNS/DUNS_PLUS_FOUR.  Specifies the possible Role values.  (EAN.UCC-
specific)

3.3.1.2 Requires that CPAId be unique, but does not describe how it is
to be determined.

3.3.1.3 Service/Action values.  The table has apparently been
truncated by the PDF converter, so the values are not visible, but are
assumed to be EAN.UCC-specific.  Implementations must be able to
support other service-action mappings.

3.3.3 Recommends that Manifest MUST be present for any payload-
containing message, which is a stronger, though sensible, requirement
than ebMS 2.0.

3.3.3.1 Reference element: Schema element should be populated, and
location attribute must point to EAN.UCC repository.

3.4.1 Use of XML Encryption required when confidentiality is required.
More specifics are needed in order to implement this usefully,
however, because the ebMS 2.0 spec so far has not addressed this area
in detail.  (What elements should be encrypted, how is payload
encryption handled, can MIME headers be protected, what are other
considerations to be taken into account for various use cases like
intermediaries, etc.)

--Pete
Pete Wenzel <pete@seebeyond.com>
SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

Thus spoke Jacques Durand (JDurand@fsw.fujitsu.com) on Fri, Jun 14, 2002 at 03:11:07PM -0700:
> All:
>  
> For those who reviewed the EAN.UCC ebXML TRP Guidelines,
> can you send me - or to the list - your comments soon?
> Or be ready to communicate them at our conf call this Monday?
>  
> Among other things we would like to hear about:
>  
> 1. Opinion on broadening our current guideline document, to an
> "implementation and deployment guidelines",
> that would cover deployment recommendations and conventions proper to
> standard groups closer to a user community,
> such as EAN.UCC (while clearly limiting their scope to EAN.UCC
> applications)
>  
> 2. Comments on the EAN Guidelines:
> What are the recommendations that are not specific to EAN.UCC and could
> apply more generally?
> Any more specific comment on the handling of:
> - CPA
> - security
> - Party ID and naming
> - message payload & manifest
> - others
>  
> Thanks,
>  
> jacques


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC