[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Summary of ER006 discussion on [Timestamp]
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]