Re: Last Call: Date and Time on the Internet: Timestamps to ProposedStandard
Joe Abley wrote: > > On Fri, Nov 09, 2001 at 05:16:09PM -0500, Keith Moore wrote: > > However, many events are actually specified relative to a particular > > timezone, and timezone offsets occasionally change with little advance > > warning. As such, this representation may not be sufficient for > > specifying dates and times of some kinds of events, particularly > > future events. > > > > In such cases it is necessary to include a representation of the timezone > > (not merely the GMT offset) along with the date of the event. This > > specification does not provide such a facility, and is therefore > > inappropriate for representation of (for example) events on a calendar. > > Is this not covered in section 1? > > o All times expressed have a stated relationship (offset) to > No - not at all. This is a BIG issue - if you want to understand it, go to the calsch archives. Or send email to the [EMAIL PROTECTED] mailing list. -Doug
Re: Last Call: Date and Time on the Internet: Timestamps to ProposedStandard
Why not just specify that dates/times are RFC2445 compliant? The calsch WG spent a long time debating these issues. In addition the date-time format used in RFC2445 is also ISO-8601 based. In addition the calsch WG has a plan (don't laugh too hard) for the usage of time zones. This draft only mentions they exist. Why does there need to be another date-time standard? Why did this not go through the calsch working group (at least cc the working group before final proposal?). This draft acknowledges the calsch WG, but the chairs (I called Pat) never saw this - nor did I. Was it sent and debated as assumed by reading the acknowledgements? 6. Acknowledgements ... Thanks are also due to participants of the IETF Calendaring/Scheduling working group mailing list, and participants of the time zone mailing list. The iCalendar date-time format is restricted to exactly one representation of date-time (not optional spaces, dashes, ...). There was a large debate on this before rfc2445 came out. We decided on ONE format for date time based on ISO-8601 MMDDTHHMMSS [+/- ...] If the intent is to be human readable - both loose. If the intent is to be machine readable - why another similar format? -Doug
Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard
Hi! The IESG writes: > The IESG has received a request from the Instant Messaging and Presence > Protocol Working Group to consider Date and Time on the Internet: > Timestamps as a Proposed Standard. > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by November 23, 2001. > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-05.txt I like to see this document and thank the authors for this piece of work! I have two comments: 1. I've used Harald Alvestrand's abfn-parser to check the two grammars (the main one, and the one in Appendix A). The second one uses the token `date-time' which is only defined in the other grammer. I guess, this should be fixed. 2. I don't like to read things like this in a standards track document (Appendix A): This information is based on the 1988 version of ISO 8601. There may be some changes in the 2000 revision. [...] This is informational only and may contain errors. I understand, that this Appendix is just informational. However, under the mentioned conditions, I wonder what the purpose of this Appendix is. To avoid people refering to it, I would suggest to simply remove it. But I would prefer to see the Appendix keep part of the document and ensured that the contents are correct and up to date, before it enters the standards track. -frank
Re: Why IPv6 is a must?
Keith Moore <[EMAIL PROTECTED]> writes: > I don't see a "killer IPv6-based business app" as likely, I think I know one. Network management and administration. There is no way in some of today's deeply NATed v4 networks to do adequate network management -- monitoring is especially hard. Overlaying a v6 network with a real address space over the NAT mess is easy, and results in being able to actually get to all the nodes being managed. -- Perry E. Metzger[EMAIL PROTECTED] -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/
whois service
Hi, I have been looking in the RFCs, but I doesn't seem to be able to find an exact answer. So I'll try drop the question in here "Must a ccTld registrar (like dk-hostmaster.dk) supply a whois service?". The reason I ask, is that whois.dk-hostmaster.dk have been taken our of service, and they only offer a web interface to the database. This removes all simple querying of any .dk domain. Thanks, Martin Djernaes
Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard
> > However, many events are actually specified relative to a particular > > timezone, and timezone offsets occasionally change with little advance > > warning. As such, this representation may not be sufficient for > > specifying dates and times of some kinds of events, particularly > > future events. > > > > In such cases it is necessary to include a representation of the timezone > > (not merely the GMT offset) along with the date of the event. This > > specification does not provide such a facility, and is therefore > > inappropriate for representation of (for example) events on a calendar. > > Is this not covered in section 1? > > o All times expressed have a stated relationship (offset) to > Coordinated Universal Time (UTC). (This is distinct from some > usage in scheduling applications where a local time and location > may be known, but the actual relationship to UTC may be dependent > on the unknown or unknowable actions of politicians or > administrators. The UTC time corresponding to 17:00 on 23rd March > 2005 in New York may depend on administrative decisions about > daylight savings time. This specification steers well clear of > such considerations.) yes, that appears to be sufficient. sorry I missed it. Keith
Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard
On Fri, Nov 09, 2001 at 05:16:09PM -0500, Keith Moore wrote: > However, many events are actually specified relative to a particular > timezone, and timezone offsets occasionally change with little advance > warning. As such, this representation may not be sufficient for > specifying dates and times of some kinds of events, particularly > future events. > > In such cases it is necessary to include a representation of the timezone > (not merely the GMT offset) along with the date of the event. This > specification does not provide such a facility, and is therefore > inappropriate for representation of (for example) events on a calendar. Is this not covered in section 1? o All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.) Joe
Re: Last Call: Date and Time on the Internet: Timestamps to ProposedStandard
Keith Moore wrote: >However, many events are actually specified relative to a particular >timezone, and timezone offsets occasionally change with little advance >warning. As such, this representation may not be sufficient for >specifying dates and times of some kinds of events, particularly >future events. This is correct. The IMPP group covered this in Minneapolis, I think. The draft alludes to the problem, but may not be explicit enough (probably isn't, if Keith felt it necessary to comment): o All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.) I believe that Keith is right, that this paragraph should include a reference to iCalendar (RFC-2445) and point readers to that for use when a simple timestamp won't do. It's a small point, but it could prevent some confusion. /\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |"Time is money, and price is information." --Russ Nelson| \/
Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard
basically I approve of publication of this document, with the following caveat about scope This representation is appropriate for dates and times for which the GMT offset as of the date and time specified is reliably known. The is usually the case for noting the current time (timestamping), or representing the times of events in the past or the near future. However, many events are actually specified relative to a particular timezone, and timezone offsets occasionally change with little advance warning. As such, this representation may not be sufficient for specifying dates and times of some kinds of events, particularly future events. In such cases it is necessary to include a representation of the timezone (not merely the GMT offset) along with the date of the event. This specification does not provide such a facility, and is therefore inappropriate for representation of (for example) events on a calendar. Keith
Re: Why IPv6 is a must?
somebody needs to define an alternative to midcom that uses IPv6 prefixes to name the addressing realms, and an algorithm to map (prefix name + NATted IPv4 address) into an IPv6 address. nobody says you have to actually be willing to route traffic to those IPv6 addresses, but you could use them in midcom as unambiguous host names for pinhole specification, and you could use them in network management. and if/when you did decide to actually route IPv6 traffic, management would be considerably simplified by being able to use the same addresses. Keith > From: "Perry E. Metzger" <[EMAIL PROTECTED]> > To: Keith Moore <[EMAIL PROTECTED]> > Cc: "Tony Hain" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > "Hans Kruse" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Why IPv6 is a must? > > Keith Moore <[EMAIL PROTECTED]> writes: > > I don't see a "killer IPv6-based business app" as likely, > > I think I know one. Network management and administration. There is no > way in some of today's deeply NATed v4 networks to do adequate network > management -- monitoring is especially hard. Overlaying a v6 network > with a real address space over the NAT mess is easy, and results in > being able to actually get to all the nodes being managed.
Re: earlier agendas
I basically think it's unrealistic to expect the schedules to be posted much earlier. Scheduling the rooms at an IETF meeting is a significant exercise in constraint-matching with limited resources. If even a few groups need to schedule a meeting, or change their room requirements close to the meeting time, there is a significant chance that several other meetings will have to change in order to accomodate that requirement. Even if we could publish the schedule earlier, it would be a Bad Idea to depend on meeting schedules not changing. It's not uncommon for meetings to be cancelled, additional meetings to be scheduled, and for meetings to be moved from one slot to another with short notice - all for good and valid reasons. Bottom line: If you schedule your travel around specific meeting times, you do so at the risk of having to change your plans or miss the meeting. We can't really solve this problem without either making the meetings signifcantly less useful or significantly increasing meeting expenses. Neither of these would be consistent with IETF's goals - or for that matter, with the goals of attendees who want to reduce costs. In my experience, almost all of the the useful work at IETF gets done outside of the meetings. So showing up just before a meeting and leaving just afterward seems unlikely to be an effective use of your resources. Keith
RE: earlier agendas
Title: RE: earlier agendas Fred, I agree with your remarks. Basically, we need 1. cheaper airfare ( we need 21 days ) 2. some of us cannot stay for the whole week so knowing the full agenda earlier is a good thing. abbie > -Original Message- > From: Fred Douglis [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 05, 2001 3:58 PM > To: [EMAIL PROTECTED] > Subject: earlier agendas > > > Before the last IETF meeting I asked some IETFers in my > company about the > rationale for having the final IETF schedule so close to the > meeting date that > one can't necessarily get a reduced-fare ticket for the days > one would want to > be there. I heard back that this is indeed a dead horse, so > I guess I'm > beating it publicly this time > > Perhaps a while back it was a given that people could afford > the time and > money to attend IETF for the entire week, and therefore the > specific agenda is > not so important. And various people say how important the > cross-fertilization is, and how terrible it would be if > people went to the > IETF meeting just for a WG meeting or two and then went home. > > I've heard this viewpoint before, and I sympathize, but I > think the whole scale > of the IETF has shifted dramatically, and the IETF should be > pragmatic. When > there were 500 people attending, and they could all come for > a week and know > everything that's going on, that was fine. But the economic > realities can > impinge on a company's ability to send dozens of people > across an ocean (or > even halfway across a continent) for a week at a time (though > I do grant that > if you do it for a week, at least you can get the cheap > airfare :), and the > people who participate have ever-increasing other demands on > their time. > > Has anyone done a study to get an idea of what fraction of > attendees currently > stay for what fraction of time? This might shed some light > on the subject. > It's one thing to decree that it's a good idea, and it's > another thing to > recognize that in practice maybe that's not the way it works > anymore... > > BTW, I also heard that WG/BOF chairs would kvetch if they had > to ask for a > slot earlier. I can't buy this whatsoever -- if the whole > schedule were known > well in advance to start and end two weeks earlier, where's the pain? > > Fred > >
Re: Why IPv6 is a must?
> > I don't see a "killer IPv6-based business app" as likely, but IPv6 > > does seem like a good way to solve some of the problems that NATs > > cause for communications between private v4 networks. It won't be > > a single app that causes businesses to shift, it will be the ability > > to run whatever protocols the businesses want to use to talk to each other. > > Hold on just a minute. Business applications are moving away > from limited client/server models towards synchronous or asynchronous > exchanges between systems that are sometimes clients and sometimes > servers. I don't want to rant at length here, but peer-to-peer business > apps are absolutely what we need for IPv6. I think we're in strong agreement. I was only pointing out that the incentive for businesses to move to IPv6 might not be one or two well-known apps that everybody uses, but a more general need to use peer-to-peer communications between businesses. Keith
Re: Why IPv6 is a must?
Tony, Keith, Keith Moore wrote: > > > The real requirement is in the other order; when > > a desireable app becomes available that works over IPv6 but fails over > > NAT. This will cause people to upgrade their OS to Solaris 8, or XP, > > etc. This is more likely to be a peer-to-peer game than any business > > app. > > I don't see a "killer IPv6-based business app" as likely, but IPv6 > does seem like a good way to solve some of the problems that NATs > cause for communications between private v4 networks. It won't be > a single app that causes businesses to shift, it will be the ability > to run whatever protocols the businesses want to use to talk to each other. Hold on just a minute. Business applications are moving away from limited client/server models towards synchronous or asynchronous exchanges between systems that are sometimes clients and sometimes servers. I don't want to rant at length here, but peer-to-peer business apps are absolutely what we need for IPv6. Brian
