W3C home > Mailing lists > Public > public-ws-policy@w3.org > November 2006

RE: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 7 Nov 2006 21:15:17 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D64165029C8F6A@uspale20.pal.sap.corp>
To: "William Henry" <william.henry@iona.com>, <public-ws-policy@w3.org>
William, 
 
I did not see our chairs respond, but i do not think that is an accurate
characterization. Apologies if it was not clear in the minutes as I was
also the scribe and defending the proposal. 
 
After a long discussion, there were 7 different proposals on the board.
As Chris Ferris also stated during the meeting, the 7 options on the
board reflected options that address generally all the use cases that we
had covered up to that point and what needs to be standardized. 
 
There is a consensus point that was reached by a mini group that will
present the results tomorrow that were trying to reconcile the options
on the board. I personally think you should wait until that
presentation/discussion is done to see whether you agree/disagree with
that direction, etc.
 
 
 
--umit
 
________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of William Henry
Sent: Tuesday, Nov 07, 2006 4:08 PM
To: public-ws-policy@w3.org
Subject: Re: NEW ISSUE: New Attribute keyword to identify 'local'
policies #3721



	I see no resolution to this issue from the f2f. 

	The discussion today was limited to 3789 from everything I could
tell. Nobody made reference to 3721 as far as I can tell.

	There was reference to "Ashok's wsp:local" which I assumed to
mean that Ashok was proposing wsp:local for the problem we were
discussing on at the f2f which was the 3789 problem.

	I remember people specifically saying that 3789 and 3721 are
different.

	So when can we discuss wsp:local ?

	Regards,
	William

	
	William G Henry
	Enterprise Architect, Technical Director, Alliances    |    IONA
Technologies Inc.
	Phone (719) 302 2302    |    Mobile: (719) 640 6868    |
e-mail: william.henry@iona.com
	Blog: www.ipbabble.com

	The SOA Revolution
	On-Demand Webcast hosted by IONA, featuring Gartner, Inc
	http://www.accelacast.com/webcasts/gartner_iona/


	On Oct 31, 2006, at 5:46 PM, William Henry wrote:


		Having watched the discussion for a while and seeing
some of the input I propose that I close #3721 without action and revise
in v.next. 

		It seems we alll agree that proprietary attributes
suffice for the moment and we can review the need for something
called/like wsp:local in the next version.

		Unless there is an objection I'll close this tomorrow
with the chair's direction.

		This is not about the wsp:optional (/wsp:advisory)
issue.

		Regards,
		William 


		On Oct 31, 2006, at 6:41 AM, Fabian Ritzmann wrote:



			Hi,
			
			We are using an attribute in our product as well
[visibility="private"].
			There clearly is a need. However, these
assertions or policies should
			never escape from the product specific space,
i.e. I'm not clear what
			advantage it would have to standardize. The only
case that I can see
			that would bring an advantage [1] is if you have
implementation
			constraints that force you to publish these
assertions or policies.
			
			Fabian
			
			
			[1] This case does not apply to our product.
			
			
			Sergey Beryozkin wrote:
			> Hi Ashok
			>
			> Are 'silent' assertions stripped of the
provider's policies before the
			> intersection engine starts working ?
			> What advantage do you think we can get if we
have a standard wsp:local
			> attribute ?
			>
			> It appears that every vendor can have a
private attribute in order to
			> mark "server-only" assertions but I'd like to
think more of what the
			> advantage we can get if we can get a standard
attribute like
			> wsp:local. It would be nice if we can come up
with some good practical
			> examples...
			>
			> Thanks, Sergey
			>
			>
			> I was talking to some of our product folks
today and, it turns out,
			> they use an attribute called "silent" to
indicate assertions that are not
			> visible to anyone outside the system and do
not take part in Policy
			> intersection.
			> I think this is what you want with 'local'.
			>
			> I agree with Umit that 'optional' does not
cover this usecase.
			>
			> All the best, Ashok
			>
			>
			>> -----Original Message-----
			>> From: public-ws-policy-request@w3.org
			>> [mailto:public-ws-policy-request@w3.org] On
Behalf Of Yalcinalp, Umit
			>> Sent: Thursday, October 19, 2006 10:56 AM
			>> To: Frederick Hirsch; ext Sergey Beryozkin
			>> Cc: William Henry; public-ws-policy@w3.org
			>> Subject: RE: NEW ISSUE: New Attribute keyword
to identify
			>> 'local' policies #3721
			>>
			>>
			>>
			>>
			>> > -----Original Message-----
			>> > From: public-ws-policy-request@w3.org
			>> > [mailto:public-ws-policy-request@w3.org] On
Behalf Of
			>> Frederick Hirsch
			>> > Sent: Thursday, Oct 19, 2006 7:31 AM
			>> > To: ext Sergey Beryozkin
			>> > Cc: Frederick Hirsch; Yalcinalp, Umit;
William Henry;
			>> > public-ws-policy@w3.org
			>> > Subject: Re: NEW ISSUE: New Attribute
keyword to identify 'local'
			>> > policies #3721
			>> >
			>> >
			>> > I believe optional and advisory are
different.
			>> >
			>> > Optional is a shortcut to provide two
policy alternatives, one with
			>> > and one without an assertion.
			>> >
			>> > I was thinking that advisory means that an
optional
			>> assertion does not
			>> > apply to the interaction per se but is
relevant to provider action
			>> > (e.g. logging etc). So it could be
implemented as optional
			>> but has the
			>> > additional semantics that it explicitly
does not affect
			>> what is on the
			>> > wire.
			>> >
			>> > Whether we want this is another question.
This information can
			>> > actually be part of the assertion
definition, so, optional would
			>> > probably be adequate by itself since the
semantics can be
			>> part of the
			>> > assertion.
			>> >
			>>
			>> Here is the problem. The information, even it
is part of the
			>> semantics of the assertion does NOT
			>>
			>> -- Allow you NOT to understand the assertion
			>> -- Thus allow mechanical means of stripping
			>>
			>> Again, the problem is with the vocabulary.
>From a client's
			>> perspective, here are the questions to ask:
			>>
			>> -- Do you need to understand the assertion
semantics?
			>> -- Can you ignore the assertion without
understanding the assertion?
			>> -- Can understanding the semantic of the
assertion allow you
			>> to ignore it and not get it involved in your
matching algorithm?
			>>
			>> These are distinct use cases.
			>>
			>> Overloading the wsp:optional marker just
complicates the
			>> matter, because it provides a cop-out for not
understanding
			>> the semantics of the assertion by creating an
alternative
			>> that only a class of clients will understand
and will engage with.
			>>
			>> In terms of logging, I do not believe that it
should be
			>> implemented by optional. Here is why.
			>>
			>> My company policy may be to log all the
messages. So, if one
			>> uses optional to designate this behavior and
advertise it as such:
			>>
			>> -- it is a lie. The provider will log all the
messages
			>> anyway. It is not an optional behavior for
the provider.
			>>
			>> -- Even the client may not need to understand
it by choosing
			>> the specific alternative that does not
include the assertion,
			>> again the client is subjected to a behavior
that is not
			>> advertised incorrectly.
			>>
			>> -- The client is not forced to understand the
logging by
			>> semantics as a side effect of using optional.
On the other
			>> hand, if logging was marked specifically
(other than
			>> wsp:optional="true") it would be possible for
the client to
			>> determine that it will or it will not use
this endpoint
			>> because logging is enforced. So, the marker
will provide the
			>> choice on the selection of an endpoint as
well. After that
			>> determination is made, it will also help the
client to use
			>> the alternative that is suitable to
communicate with the
			>> endpoint as the assertion can be ignored for
the client
			>> interaction purposes.
			>>
			>>
			>> IMO, overloading the two cases is simply does
NOT represent
			>> what is required in reality and can not
really be solved by
			>> the semantics of the assertion. We do not
have a provision to
			>> to utilize the semantics of an assertion to
include or not
			>> include in the intersection algorithm
currently.
			>>
			>> That is the problem I see with using optional
category for
			>> both optional vocabulary and optional
behavior.
			>>
			>>
			>>
			>> > Thus I suspect we do not need the advisory
attribute, or am I
			>> > forgetting something?
			>>
			>> See above,
			>>
			>> >
			>> > regards, Frederick
			>> >
			>> > Frederick Hirsch
			>> > Nokia
			>> >
			>>
			>> --umit
			>>
			>> >
			>> > On Oct 19, 2006, at 2:36 AM, ext Sergey
Beryozkin wrote:
			>> >
			>> > > Hi Umit
			>> > >
			>> > > "It is my understanding that presence of
wsp:local or
			>> wsp:advisory
			>> > > would provide the same functionality."
			>> > >
			>> > > No, as far as I understand it won't.
wsp:local mark
			>> assertions which
			>> > > should be stripped off by a provider and
if a provider
			>> can't do it
			>> > > then they must be ignored completely by a
requester.
			>> > >
			>> > > wsp:advisory is similar, but it's more
loose in that it permits a
			>> > > client to actually *optionally* use the
assertion, to optionally
			>> > > include in the intersection algorithm,
etc.
			>> > >
			>> > > that's the same as wsp:optional. Perhaps
the semantical
			>> meanings are
			>> > > different between wsp:optional and
wsp:advisory but in
			>> the end both
			>> > > would permit the client to optionally
choose an assertion and do
			>> > > something about it. IMHO they'd overlap
and more
			>> confusion and hence
			>> > > more complexity.
			>> > >
			>> > > Actually, I think wsp:advisory is what
wsp:optional is, they're
			>> > > identical in my naive view. wsp:advisory
*advises* the
			>> requester and
			>> > > this is something a provider is
additionally capable of
			>> (accepting
			>> > > mtom messages, being replicatable, etc)
and a requester
			>> is free to
			>> > > notice it and do something about it or
ignore it.
			>> > >
			>> > > wsp:local is not the same as
wsp:advisory.
			>> > > wsp:optional is not the same as wsp:local
wsp:optional is
			>> similar to
			>> > > wsp:advisory
			>> > >
			>> > > Modified wording for wsp:optional would
be a simpliest and non-
			>> > > ambiguous solution IMHO.
			>> > > If a policy author wants an assertion be
visible then this is
			>> > > assertion is either optional or not
optional.If it's
			>> optional then
			>> > > it's advisory to client in that a client
free to notice it and do
			>> > > something about it.
			>> > > If a policy author does not want an
assertion be visible to an
			>> > > ultimate requester then it's wsp:local.
			>> > >
			>> > > I'd prefer :
			>> > > wsp:optional and wsp:local
			>> > > or
			>> > > wsp:advisory and wsp:local
			>> > >
			>> > > Thanks, Sergey
			>> > > ----- Original Message -----
			>> > > From: Yalcinalp, Umit
			>> > > To: Sergey Beryozkin ; William Henry
			>> > > Cc: Frederick Hirsch ;
public-ws-policy@w3.org
			>> > > Sent: Wednesday, October 18, 2006 8:30 PM
			>> > > Subject: RE: NEW ISSUE: New Attribute
keyword to identify
			>> 'local'
			>> > > policies #3721
			>> > >
			>> > > It is my understanding that presence of
wsp:local or wsp:advisory
			>> > > would provide the same functionality. So,
the question is
			>> to come up
			>> > > with an appropriate name everyone agrees.
			>> > >
			>> > > --umit
			>> > >
			>> > >
			>> > > From: Sergey Beryozkin
[mailto:sergey.beryozkin@iona.com]
			>> > > Sent: Wednesday, Oct 18, 2006 10:28 AM
			>> > > To: William Henry
			>> > > Cc: Frederick Hirsch; Yalcinalp, Umit;
public-ws-policy@w3.org
			>> > > Subject: Re: NEW ISSUE: New Attribute
keyword to identify
			>> 'local'
			>> > > policies #3721
			>> > >
			>> > > HI William
			>> > >
			>> > > "The idea of using this as a mechanism
for providers to strip on
			>> > > configuration information gets weaker -
especially when
			>> making the
			>> > > above argument.  "How do it know?" ;-) to
strip or not to strip?
			>> > >
			>> > > That ideas was that wsp:local would
provide a consistent approach
			>> > > for providers to have a way of stripping
out such local policies
			>> > > before publishing. But how do you
distinguish between
			>> those that get
			>> > > stripped out and those that get
advertised."
			>> > >
			>> > > Just don't put wsp:local on those
assertions you want to make
			>> > > visible to requesters.
			>> > > I think what you're talking about is very
close to waht Frederick
			>> > > suggests with awsp:advisory attribute.
They mark assertions of
			>> > > interest to providers, clients might
choose to notice it or
			>> > ignore it.
			>> > >
			>> > > So suppose we have wsp:advisory, I thinbk
it would be a
			>> > better name
			>> > > then.
			>> > > And we also have wsp:optional which can
be used to mark
			>> assertions
			>> > > which a requester can choose to ignore.
			>> > >
			>> > > I think we'll have an overlap and more
confusion as a result. I
			>> > > think I like wsp:advisory, just feeling
that if we adopt a new
			>> > > attribute overlapping with wsp:optional
then we'll have more
			>> > > complexity in the end
			>> > >
			>> > > I believe it will be simplier if a
wording for wsp:optional is
			>> > > updated given that wsp:optional is about
assertions which
			>> are not
			>> > > optional for a provider but optional for
a requester to
			>> consume... .
			>> > >
			>> > > Cheers, Sergey
			>> > > ----- Original Message -----
			>> > > From: William Henry
			>> > > To: Beryozkin, Sergey
			>> > > Cc: Frederick Hirsch ; Yalcinalp, Umit ;
public-ws-policy@w3.org
			>> > > Sent: Wednesday, October 18, 2006 6:05 PM
			>> > > Subject: Re: NEW ISSUE: New Attribute
keyword to identify
			>> 'local'
			>> > > policies #3721
			>> > >
			>> > > Hi folks,
			>> > >
			>> > > The more I think about this the more I'm
convinced that
			>> it is more
			>> > > appropriate for advertising features or
qualities of
			>> service that
			>> > > do not require action by the consumer. So
using an
			>> earlier example
			>> > > that Sergey used with a modification
			>> > >
			>> > >  <wsdl:port>
			>> > >  <soap:address location="http://foo"/>
			>> > >  <wsp:Policy>...
			>> > >    <sp:HTTPSToken/>
			>> > >    <custom:HighAvailability
wsp:local="true"/>
			>> > >  </wsp:Policy>
			>> > > </wsdl:port>
			>> > >
			>> > > Though HighAvailability might require the
server to do
			>> some extra
			>> > > configuration the reason for putting it
in the WSDL is not for
			>> > > configuration but for providing extra
information that MAY be of
			>> > > interest to the consumer but would NOT
prohibit the
			>> consumer from
			>> > > using the service if they can't
understand it - they can
			>> ignore it.
			>> > >
			>> > > The idea of using this as a mechanism for
providers to strip on
			>> > > configuration information gets weaker -
especially when
			>> making the
			>> > > above argument.  "How do it know?" ;-) to
strip or not to strip?
			>> > >
			>> > > That ideas was that wsp:local would
provide a consistent
			>> approach
			>> > > for providers to have a way of stripping
out such local policies
			>> > > before publishing. But how do you
distinguish between those that
			>> > > get stripped out and those that get
advertised.
			>> > >
			>> > > Furthermore people in this group would
say that that is
			>> really up
			>> > > to the implementor and they can be
responsible. (Dan holds this
			>> > > position)
			>> > >
			>> > > HOWEVER, in this case this is also the
issue of portability. A
			>> > > provider that is using policies defined
by another vendor
			>> that has
			>> > > significance for the provider but not for
the consumer
			>> would like
			>> > > to understand how to handle this
consistently. So for
			>> third party
			>> > > policies one can imagine that a
consistent way of
			>> stripping these
			>> > > out would be useful.
			>> > >
			>> > > So then does wsp:local (or whatever it's
name is) have
			>> > true, false,
			>> > > provideronly ??????? Otherwise how do we
distinguish between
			>> > > advertise-as-a-feature Vs.
provider-should-strip-before-publish?
			>> > >
			>> > > Regards,
			>> > > William
			>> > >
			>> > >
			>> > > On Oct 6, 2006, at 3:17 AM, Beryozkin,
Sergey wrote:
			>> > >
			>> > >> Hi Frederick,
			>> > >>
			>> > >> Sorry for a late response.
			>> > >>
			>> > >> First of all I'd like to draw a line
between wsp:optional and
			>> > >> something like wsp:local. We do not see
any relationship
			>> between
			>> > >> wsp:optional and wsp:local.
			>> > >>
			>> > >> The differentiator between wsp:local and
wsp:optional is
			>> simple.
			>> > >> wsp:local marks assertions which are
only intended for a
			>> > provider.
			>> > >> Provider *should do the best effort to
strip such
			>> assertions out*
			>> > >> of the policy to be published. If such
an assertion is
			>> > leaked then
			>> > >> the only thing the client knows about it
is that it has to
			>> > skip it
			>> > >> and move on to the next assertion.
Client may choose to
			>> notice it
			>> > >> but there're absolutely no obligations
on the provider's
			>> > behalf as
			>> > >> to whether this assertion will be
honoured or not.
			>> > >> wsp:local assertions are not the ones
WS-Policy
			>> framework primer
			>> > >> talks about when recommending best
practices for policy
			>> authors.
			>> > >> Good interoperatable policy assertion is
the one which is
			>> > >> understood and used by both parties
involved. So why do we even
			>> > >> want to create a noise in the WS-Policy
space with
			>> wsp:local ? We
			>> > >> feel there might some scenarios which
I'll address in a
			>> follow-up
			>> > >> message...
			>> > >>
			>> > >> On the contrary wsp:optional and the
whole optionality tar
			>> > ball is
			>> > >> about assertions which may be of use for
requesters. wsp:local
			>> > >> assertions may not be of use for
requesters.
			>> > >>
			>> > >> Optionality is a hint to a requestor.
>From the
			>> provider's point
			>> > >> view wsp:optional assertions are not
optional at all, it
			>> > >> guarantees to support them.
			>> > >>
			>> > >> Given what I've said I'd like to say
that I agree with
			>> some parts
			>> > >> of your message but here're two parts
which I'n not happy
			>> > about :-) :
			>> > >>
			>> > >> > 2) The client can choose to include or
not in intersection
			>> > >> operation,
			>> > >> > depending on interest.
			>> > >> I don't think wsp:local assertions can
be of any interest to a
			>> > >> client. I don't think we need a new
attribute like
			>> wsp:local for
			>> > >> assertions which a client may want to do
something
			>> useful about.
			>> > >> Policy alternatives/wsp:optional will do
just fine for
			>> > this to work.
			>> > >>
			>> > >> > Without wsp:local/wsp:optional all
assertions MUST be
			>> included in
			>> > >> > intersection operation.
			>> > >> Please see above. Lets just draw the
line between wsp:local and
			>> > >> wsp:optional :-)
			>> > >>
			>> > >> > 3) This is additional information that
a client might wish to
			>> > >> consider.
			>> > >> Please see above. If it is of any use to
a client then
			>> it's not a
			>> > >> wsp:local assertion
			>> > >>
			>> > >> Thanks, Sergey
			>> > >>
			>> > >>
			>> > >>
			>> > >>
			>> > >> > Sergey
			>> > >> >
			>> > >> > It was mentioned by Fabian on the call
today that different
			>> > >> > assertions can have different
properties, and I think
			>> > this is where
			>> > >> > we are heading with
wsp:local/wsp:advisory (alternative names
			>> > >> for the
			>> > >> > same concept and attribute)
			>> > >> >
			>> > >> > In general an assertion present in a
policy assertion
			>> > means that
			>> > >> the
			>> > >> > client MUST understand that assertion
and that the
			>> provider WILL
			>> > >> > support it. This is regardless of
whether the assertion
			>> > has a wire
			>> > >> > implication.
			>> > >> >
			>> > >> > Using wsp:optional enables policy
alternatives to be easily
			>> > >> created,
			>> > >> > either requiring and asserting the
assertion and not.
			>> > >> >
			>> > >> > However there are cases where
wsp:optional is not what
			>> > is desired,
			>> > >> > and where wsp:local/wsp:advisory is
needed.
			>> > >> >
			>> > >> > The use case is that a provider should
be able to state an
			>> > >> assertion
			>> > >> > that will be in effect, but it obeys
the following properties:
			>> > >> >
			>> > >> > 1) It can safely be ignored by web
service client,
			>> even though
			>> > >> true.
			>> > >> > The provider is making no obligation
to the client. It has no
			>> > >> > essential impact on a contract between
client and provider.
			>> > >> >
			>> > >> > An example is an assertion that server
logging is
			>> performed (e.g.
			>> > >> > clients might not care about it, but
it is *not*
			>> optional in the
			>> > >> > sense that the server *will* do it).
			>> > >> >
			>> > >> > 1a) Assertions that imply mutual
contract between client and
			>> > >> provider
			>> > >> > cannot be wsp:local/wsp:advisory.
These include
			>> > >> >
			>> > >> > + Assertions that impact wire formats
			>> > >> > + Assertions that define quality of
service (service level
			>> > >> > agreements), quality/reliable
messaging.
			>> > >> >
			>> > >> > 2) The client can choose to include or
not in intersection
			>> > >> operation,
			>> > >> > depending on interest.
			>> > >> > Without wsp:local/wsp:optional all
assertions MUST be
			>> included in
			>> > >> > intersection operation.
			>> > >> >
			>> > >> > 3) This is additional information that
a client might wish to
			>> > >> consider.
			>> > >> >
			>> > >> > we need to distinguish optional for
agreement of a
			>> > contract with or
			>> > >> > without an asserted
requirement/capability and
			>> > informational items
			>> > >> > that are not necessarily optional.
			>> > >> >
			>> > >> > regards, Frederick
			>> > >> >
			>> > >> > Frederick Hirsch
			>> > >> > Nokia
			>> > >> >
			>> > >> >
			>> > >> > On Oct 4, 2006, at 4:30 AM, ext Sergey
Beryozkin wrote:
			>> > >> >
			>> > >> >> Hi
			>> > >> >>
			>> > >> >> Reference to the thread[1] is
misleading IMHO.
			>> > >> >> I was stating from the start that a
proposed wsp:local
			>> > was nothing
			>> > >> >> to do with what is discussed in that
thread. The semantics of
			>> > >> >> wsp:local are : mark assertions which
*must be ignored* by a
			>> > >> >> requester. That is it, no more
semantics...
			>> > >> >>
			>> > >> >> Thanks, Sergey
			>> > >> >> ----- Original Message -----
			>> > >> >> From: Yalcinalp, Umit
			>> > >> >> To: public-ws-policy@w3.org
			>> > >> >> Sent: Tuesday, October 03, 2006 11:44
PM
			>> > >> >> Subject: Re: NEW ISSUE: New Attribute
keyword to
			>> > identify 'local'
			>> > >> >> policies #3721
			>> > >> >>
			>> > >> >>
			>> > >> >> There has been a lot of discussion on
Issues 3721 and
			>> 3564. I am
			>> > >> >> posting this response to this thread
in order to
			>> illustrate why
			>> > >> >> there are two separate issues that
need to be tackled
			>> > >> >> independently. However, they are NOT
the same issue.
			>> > >> Utilization of
			>> > >> >> optional assertions is a separate
concern and those
			>> > issues must
			>> > >> not
			>> > >> >> be lumped together.
			>> > >> >>
			>> > >> >> Please find some comments in a
different thread that
			>> > explains why
			>> > >> >> there are two separate issues here
for the details [1].
			>> > >> >>
			>> > >> >> Thanks,
			>> > >> >>
			>> > >> >> --umit
			>> > >> >>
			>> > >> >> [1]
			>> >
http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/
			>> > >> >> 0016.html
			>> > >> >>
			>> > >> >> ----------------------
			>> > >> >>
			>> > >> >> Dr. Umit Yalcinalp
			>> > >> >> Architect
			>> > >> >> NetWeaver Industry Standards
			>> > >> >> SAP Labs, LLC
			>> > >> >> Email: umit.yalcinalp@sap.com Tel:
(650) 320-3095
			>> > >> >> SDN:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
			>> > >> >> --------
			>> > >> >> "First they ignore you, then they
ridicule you,
			>> > >> >> then they fight you, then you win."
Gandhi
			>> > >> >>
			>> > >> >>
			>> > >> >
			
			
			
Received on Wednesday, 8 November 2006 05:16:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:43 GMT