[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Summary of ER006 discussion on [Timestamp]
|
Marc, I think you have summarized the
discussion correctly below. My personal preference is for the arguments
given in A, however if we do want to close this without action, and accept the
spec as is, which in my opinion still leaving some ambiguity, then as I
understand it, sending a timestamp when SP does not require it, should be treated
as non-conformance to spec, and hence SP should generally reject such messages. The only prevailing concern for me is
that the wording in the spec in its present nature does introduce two schools
of thought given in the arguments below, and which can be seen in the
implementations, which also potentially hampers interop. I think, one way or the other, and
decision should simply do away with ambiguities that could arise while
implementing the spec. Thanks Aditya From: Marc Goodner
[mailto:mgoodner@microsoft.com] This
message is an attempt at unwinding a discussion Aditya and I had over a pretty
long time period about ER006. I haven’t run this by him, so hopefully he’ll
reply on the list if he thinks I’ve represented this correctly or not. Issue
ER006 is concerned with the statement in SP that if [Timestamp] is false, then
<wsu:Timestamp> must not be present inside <wsse:Security> header. It
has been observed in interop testing that there are implementations whose
clients will transmit [Timestamp] when it is set to false by the service. There
doesn’t seem to be any disagreement that clients that do this are not
correct with respect to the current spec. It
has also been observed that many implementations services will accept
<wsu:Timestamp> in the <wsse:Timestamp> header when they have set
[Timestamp] to be false. The spec has wording that permits this behavior. There
is some disagreement on the interpretation of the wording that permits this depending
on the interpretation of the [Timestamp] rule itself (see closing points in
lists below). The
question on the table is should a) the spec be changed to loosen the rule from
<wsu:Timestamp> must not appear to <wsu:Timestamp> may be ignored
or b) the spec is correct and the issue should be closed with no action? Aditya
and I have not been able to agree on this. This
is difficult to unwind, I’m attempting to represent the arguments made
for each position a and b above. They can also be read as point/counterpoint,
but I felt keeping them clearly separated was the best way to present this. Arguments
for a) – loosen rules on [Timestamp] set to false ·
If the initiator sends more than
what the service policy requires the service provider should treat it as
redundant information and ignore it. ·
Service providers should only
check the appearance of <wsu:Timestamp> against Layout rules when
[Timestamp] is false. ·
Almost all participants in interop
ignored an unwanted <wsu:Tiemstamp>. ·
Saying when [Timestamp] set to
false that <wsu:Timestamp> must not appear could be interpreted as
messages that include it must not be accepted. The statement that a service can
accept messages that do not conform to its policy seems contradictory to that
interpretation. As an implementer which viewpoint should take precedence? Arguments
for b) – close with no action ·
There are rules in the Layout
assertions for where <wsu:Tiemstamp> appears, this is not always extra
information that can be safely ignored when it appears unexpectedly. ·
Changing the guidance as requested
for [Timestamp] would introduce inconsistencies into the SP model. The SP model
is that the initiator MUST send exactly what the service provider asks for; no
less, no more. ·
SP already permits a service to
accept extra information such as a unrequested Timestamp in the header if
present. See section 2.3 “Note also that a service may choose to accept messages that do
not conform to its policy.” ·
From an implementation perspective
being strict on what you send and liberal on what you accept is often
beneficial for wider interop. One reason for accepting messages that don’t
conform to policy may be for wider interop with incorrect clients and is the
best explanation for what was seen in interop testing. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]