The solution is simple - move to TAI. That is the _true_ time, what
the master clocks actually keep. UTC is just a variant for creatures
living on the surface of the Earth.
Being one of those creatures, I voted for keeping leap seconds. UTC
seems to fit the global Internet quite nicely,
On 1/23/12 3:27 AM, Michael Richardson wrote:
Eliot == Eliot Lear l...@cisco.com writes:
Can you tell me which protocols use future timestamps in an
moving form (not stored at rest in a certificate in a DANE RR,
for instance), which care about discrepancies of less than 1
On 20 Jan 2012, at 00:37, Stuart Cheshire wrote:
Good suggestion Brian.
I just called our corporate travel department and got the same rate as IETF,
including free Internet and breakfast, and cancel by 6 PM on check-in day.
Nice if you have such a department :)
I booked a room by fax
Clint Chaplin clint.chap...@gmail.com wrote:
On Fri, Jan 20, 2012 at 10:04 AM, Ofer Inbar c...@a.org wrote:
If the main problem with leap seconds is their future
unpredictability, isn't there a compromise option between the status
quo and no more leap seconds? Couldn't they come up
Just curious, but I've often used the formulation:
day = (now - now % 86400)
where now is the output of gmtime() of equivalent to calculate the number
of days since the epoch.
How is this affected (or not) by the presence of leap seconds, and/or any
proposal to remove them.
Ray
Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Time is and always will be an arbitrary measurement scheme, and the only
thing that makes sense for the Internet is to use the same arbitrary
scheme as everybody else. We just have to suck up the resulting
inconveniences, as GPS has to. It
Ray Bellis ray.bel...@nominet.org.uk wrote:
day = (now - now % 86400)
where now is the output of gmtime() of equivalent to calculate the
number of days since the epoch.
How is this affected (or not) by the presence of leap seconds, and/or
any proposal to remove them.
It is not
On 2012-01-23 16:46, The IESG wrote:
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard
...
Please see my
On 2012-01-23 18:24, Mike Jones wrote:
As editor of the Oauth Bearer spec, I believe that these comments have been
well understood and considered by the working group. I do understand that the
working group's consensus position is different than Julian's. See these notes
documenting that
On Mon, Jan 23, 2012 at 4:52 AM, Alessandro Vesely ves...@tana.it wrote:
The solution is simple - move to TAI. That is the _true_ time, what
the master clocks actually keep. UTC is just a variant for creatures
living on the surface of the Earth.
Being one of those creatures, I voted for
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol'
draft-ietf-oauth-v2-23.txt as a Proposed Standard
There are some downrefs in this document that need to be called out in
the Last Call
On 1/23/12 11:31 AM, Barry Leiba wrote:
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol'
draft-ietf-oauth-v2-23.txt as a Proposed Standard
There are some downrefs in this document
I'd like to whole heartedly endorse this suggestion and encourage a variety
of IETF Subject matter experts to give talks relevant to the FCC.
I personally help arrange two seminars at the FCC at the invitation of Doug
Sicker, Henning's predecessor as CTO
The first on was a tutorial on SIP and
At 10:23 23-01-2012, The IESG wrote:
The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'xNAME RCODE and Status Bits Clarification'
draft-ietf-dnsext-xnamercode-00.txt as a Proposed Standard
The IESG plans to make a decision in the next
Is there an appropriate list/wiki/etc. to discuss possible room sharing
arrangements? I'm not going to be able to register for the event until I
get this worked out, so I can use the meeting-specific attendees list
for that purpose.
If there is no such place, I'll state here that I'm
Hi Kevin
You can register at https://www.ietf.org/meeting/register.html
You can hold off on paying until early March.
That will give you the ability to edit the meeting wiki:
https://www.ietf.org/registration/MeetingWiki/wiki/ietf83
You can easily add a page there for what you're looking for.
On 01/23/2012 02:42 PM, Yoav Nir wrote:
Hi Kevin
You can register at https://www.ietf.org/meeting/register.html
You can hold off on paying until early March.
Of course, I should have realized that.
That will give you the ability to edit the meeting wiki:
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol'
draft-ietf-oauth-v2-23.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Bulk DHCPv4 Lease Query'
draft-ietf-dhc-dhcpv4-bulk-leasequery-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments
The IESG has received a request from the SIP for Instant Messaging and
Presence Leveraging Extensions WG (simple) to consider the following
document:
- 'Multi-party Chat Using the Message Session Relay Protocol (MSRP)'
draft-ietf-simple-chat-13.txt as a Proposed Standard
The IESG plans to make
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Forcerenew Nonce Authentication'
draft-ietf-dhc-forcerenew-nonce-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'xNAME RCODE and Status Bits Clarification'
draft-ietf-dnsext-xnamercode-00.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments
The IESG has approved the following document:
- 'Authentication Failure Reporting using the Abuse Report Format'
(draft-ietf-marf-authfailure-report-10.txt) as a Proposed Standard
This document is the product of the Messaging Abuse Reporting Format
Working Group.
The IESG contact persons are
The IESG has approved the following document:
- 'OSPFv2 Multi-Instance Extensions'
(draft-ietf-ospf-multi-instance-09.txt) as a Proposed Standard
This document is the product of the Open Shortest Path First IGP Working
Group.
The IESG contact persons are Stewart Bryant and Adrian Farrel.
A
The IESG has approved the following document:
- 'Moving A6 to Historic Status'
(draft-jiang-a6-to-historic-00.txt) as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Ralph Droms.
A URL of this
The IESG has approved the following document:
- 'DNS Extensions to Support IPv6 Address Aggregation and Renumbering '
RFC 2874 as a Historic RFC
This document is the product of the IP Version 6 Working Group.
The IESG contact persons are Ralph Droms and Jari Arkko.
A URL of this RFC is:
27 matches
Mail list logo
