Re: the place(s) for smtp discussion?

[Frank Ellermann]

Pekka Savola wrote:
 
> I guess [EMAIL PROTECTED] should be listed on
> https://datatracker.ietf.org/public/nwg_list.cgi

I've submitted it, let's see what Scott and Paul think, bye



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Status of audio streaming for IETF 63. (revisited)

[Joel Jaeggli]

Just a quick update, and a question. Can anyone would would like to 
recieve the stream, but would find 64Kb/s to be prohibitively high-bitrate 
please contact me, so I know if there in fact are any?


The new streaming effort continues for IETF 63. All eight parallel tracks as 
well as the plenaries will be covered. It is our hope that this effort will 
continue to provide useful timely and accessible access to the proceedings of 
the IETF as they happen.


An internet draft (revised since IETF 62) desscribing what the project intends 
to accomplish, and the efforts up to this point is available at:


http://www.ietf.org/internet-drafts/draft-jaeggli-ietftv-ng-01.txt

Streams are to be delivered as 64Kb/s unicast-http-streamed mp3 audio, a 
popular and relativly standard way to deliver internet radio. Most platforms 
should have a client immediatly available (windows media player, quicktime, 
real, winamp, vlc, mplayer, zinf, etc) capable of playing back the stream.


Streaming begins at 0730 CEST (UTC/GMT +2), August 1, 2005.

Visit the streaming webpage for additional information, access to the 
streams, updated broadcast schedule and links to the archived media as 
they appear.


http://videolab.uoregon.edu/events/ietf/ietf63.html

To test your client against a currently active stream of the same type prior to 
the the meeting, visit the webpage for instruction.


regards
joelja


--
--
Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-klensin-iana-reg-policy-01.txt

[John C Klensin]

--On Monday, 25 July, 2005 09:31 +0200 Brian E Carpenter
<[EMAIL PROTECTED]> wrote:

> I'm a bit surprised that this version retains without comment
> the retroactive clause that several people commented adversely
> on:

> In summary, unless the "scarcity" rules of Section 3
> apply, this
> document updates all "IANA registration" documents and
> "IANA
> considerations" sections of documents to clarify the point
> that
> registration review is to focus on the issues above,
> rather than on
> concerns about, e.g., whether one protocol approach is
> better than
> another one.

> Without arguing about the guidelines for *future* IANA
> Considerations, I really don't see how we can reasonably make
> a blanket revision of existing ones, that were presumably
> developed intentionally in their present form.

Probably it should have been explicitly flagged, for which I
apologize.  But it intentionally said "clarify" and one cannot
"clarify" something that already clearly means something else.
The difficulty, IMO, is with the belief about intentions:  There
are probably exceptions, but the majority of the IANA
considerations sections that I looked at before writing that
section suffer, unsurprisingly, from the same core problem from
which, in retrospect RFC 2434 suffers: they specify who does the
evaluation, but not the criteria for making a decision.  To the
extent to which that is true, the above paragraph was intended
to supply missing evaluation criteria, which doesn't change any
existing and documented intentions.  It was not intended to
change either the established models of by whom and how the
evaluation is done or any clear statements about evaluation
criteria (if and where those exist).

Nor was this intended to change any registration that had
already been made.

In retrospect, it would have been better to write that statement
with something like "...in the absence of specific evaluation
criteria in the existing documents...".  I will mark something
equivalent to that into the working version in the event that
there is a -02.   But I suspect that change would not have made
"those who commented adversely" much happier.

> Thinking about it, the last clause of the paragraph above is
> quite surprising. Even for IP version numbers, it wasn't done
> this way (6, 7, 8 and 9 were all assigned to competing
> proposals for IPng). 

The IPng effort operated in a way that made all of those
competing proposals IETF efforts, developed (and their numbers
assigned) under the umbrella and leadership of IETF WGs and an
IETF special-purpose area.   These assignments were also made by
the "old" IANA, rather that under close technical supervision of
registrations by the IESG or its designees.  The IANA reg policy
document is intended to clarify things so that the registration
mechanisms are not used to stifle innovations that do not
originate in IETF processes, so it isn't clear to me that the
above example is relevant to the matter at hand.

> I think this clause is worrying about something that never
> happened.

If there were no concerns about things that have happened and
the associated clear opportunities for misunderstandings and
accusations about abuse, the document never would have been
written.  If it addresses some issues that have not specifically
occurred, that is normally called "establishing principles" as
contrasted with "confining oneself to fighting the last war".

> I would be happier if the above paragraph said something like
> 
> In summary, unless the "scarcity" rules of Section 3
> apply, this
> document describes the way in which "IANA registration"
> documents
> and "IANA considerations" sections of documents will be
> interpreted
> in future, to clarify the point that registration review
> is to focus
> on the issues above.

Noted, and noted in the working version of -02.

   john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: calendar file for IETF

[Brian Rosen]

So, I just had to try it, even though my company insists on MS Exchange for
calendars.  Of course it didn't work, and I never expected it to work.
However, the error message is at least amusing:

  This error can appear if you have attempted to save a recurring 
  Lunar appointment in iCalendar format.
  To avoid this error, set the appointment option to Gregorian instead of
  Lunar.

Brian

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Eliot Lear
Sent: Saturday, July 23, 2005 4:35 AM
To: Cyrus Daboo; IETF Discussion
Cc: Eliot Lear
Subject: Re: calendar file for IETF

An additional update reflecting yesterdays changes is now available at
http://www.ofcourseimright.com/~lear/ietf63.ics.

Additional stuff:

 - UIDs *should* be stable across changes.
 - An attempt has been made to make proper use of SEQUENCE
 - An attempt has been made to parse out LOCATION information
 - Garbage in/Garbage out problem repaired.
 - Several bad dates have been corrected.

Usual cautions apply.  This calendar file could blow up any tool it is
applied to.  But it didn't blow up iCal, at least.

Eliot

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Oasis office format MIME type

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-


I have:

application/vnd.sun.xml.impress.template;ooffice %s
application/vnd.sun.xml.draw;ooffice %s
application/vnd.stardivision.draw;ooffice %s
application/x-stardraw;ooffice %s

In my .mailcap. But that doesn't look very official. (vendor sun?)

I haven't found an officially registered MIME type for Open office.
is there a process afoot to do this?


I've also come to realize that systems that are abusing the
application/octet-stream, and then expecting applications to look at the
file extension are contributing to risk due to virus/trojan spam.

That is because users can not "conveniently" turn off the extension ->
application mapping.

- -- 
] Michael Richardson  Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com   Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/www.xelerance.com/training/   |device driver[
]I'm a dad: http://www.sandelman.ca/lrmr/ [
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQuQNFYqHRg3pndX9AQFkewP+J+uPeUbvTgYQiT22mpsOEK8XHK6+eQRY
rst3i5C5FRHvcZgCXx0a0S3uudsqvjIa3ByEvO2kAYKdxANutnTRO6nzRCKMW4hP
Zv5QF5weaKHa+r6cnFPeoYorR2JcR8RFjEBkknnjcEzrVyZM/lB3ghWFcPUZenCy
YlAOoV+T9zE=
=HYg/
-END PGP SIGNATURE-

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ietf mailing list Acceptable Use Policy

[JFC (Jefsey) Morfin]

At 16:09 25/07/2005, Dave Crocker wrote:


>  But as he said, that page doesn't help us define what makes an ietf list,
>  just lists the ones that are.


right.

the goal of this particular page is the equivalent of NOTE WELL.  It is
intended to be used as a way of a priori declarations of list rules,
rather than more general aspects of mailing list.


May be a foot-note for RFC 2028 which is quoted in one of the RFC?

I suggest that an "ietf related list" is to be understood as a list which 
can practically apply the IETF rules decribed by the quoted RFCs, ie. 
having an AD and appeal capability to IESG/IAB?
This should exclude IANA lists which should submitted to equivalent rules 
by IANA?


jfc




  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ietf mailing list Acceptable Use Policy

[Dave Crocker]

>  But as he said, that page doesn't help us define what makes an ietf list,
>  just lists the ones that are.


right.

the goal of this particular page is the equivalent of NOTE WELL.  It is
intended to be used as a way of a priori declarations of list rules,
rather than more general aspects of mailing list.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: ietf mailing list Acceptable Use Policy

[Susan Harris]

I've put together a draft web page that is intended to be usable to any 
working group mailing list.  I'd appreciate review comments on it.


It is at:

  


Looks good Dave - thanks for doing this.  One thing that could be added is 
info on "what is an ietf list and what isn't."  Harald pointed to:


https://datatracker.ietf.org/public/nwg_list.cgi

But as he said, that page doesn't help us define what makes an ietf list, 
just lists the ones that are.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Cautionary tale: Paris pickpockets

[Brian E Carpenter]

Dave is correct; I'd just like to mention that this is nothing specific
to Paris - I've personally had to eject extraneous hands from my pocket
in both London and Geneva - so it's worth a bit of extra care. Also
watch out for people lifting items of luggage - do NOT look away from
your bags even for ten seconds.

   Brian

Dave Crocker wrote:

Folks,

There is quite a bit of publicity about pickpockets in Paris, generally, 
and especially in Metro stations.  In Versailles, they make regular 
public-address announcements about it.

...


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

the place(s) for smtp discussion?

[Pekka Savola]

Hi,

Following up on a very old thread, because a friend asked me where to 
look for the latest work on SMTP and I had to scratch my head a bit as 
an appropriate mailing lists couldn't be found anywhere on the IETF 
web pages..


I guess [EMAIL PROTECTED] should be listed on 
https://datatracker.ietf.org/public/nwg_list.cgi , if it's used as a 
major venue for discussion (and IETF IPR rules probably apply) ?


The non-wg list currently only includes [EMAIL PROTECTED]

On Wed, 15 Jun 2005, Keith Moore wrote:
[... about the spamops document ...]
I recommend that followups be sent to the [EMAIL PROTECTED] list, as this 
seems to be the most appropriate place for the discussion.


Keith



--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-klensin-iana-reg-policy-01.txt

[Brian E Carpenter]

I'm a bit surprised that this version retains without comment the
retroactive clause that several people commented adversely on:

   In summary, unless the "scarcity" rules of Section 3 apply, this
   document updates all "IANA registration" documents and "IANA
   considerations" sections of documents to clarify the point that
   registration review is to focus on the issues above, rather than on
   concerns about, e.g., whether one protocol approach is better than
   another one.

Without arguing about the guidelines for *future* IANA Considerations,
I really don't see how we can reasonably make a blanket revision of
existing ones, that were presumably developed intentionally in their
present form.

Thinking about it, the last clause of the paragraph above is quite
surprising. Even for IP version numbers, it wasn't done this way
(6, 7, 8 and 9 were all assigned to competing proposals for IPng).
I think this clause is worrying about something that never happened.

I would be happier if the above paragraph said something like

   In summary, unless the "scarcity" rules of Section 3 apply, this
   document describes the way in which "IANA registration" documents
   and "IANA considerations" sections of documents will be interpreted
   in future, to clarify the point that registration review is to focus
   on the issues above.


   Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf