No more boredom! 1273

Below is the result of your feedback form.  It was submitted by
 ([EMAIL PROTECTED]) on Thursday, July 5, 2001 at 01:27:39
---

: Looking for new people to talk to? Find someone to share your interests with online 
:or in person. Better yet find your soul mate! Stop being bored online. http://www.geocities.com/finderjz";>Click Here!!






73611

---

draft-krebs-gnuqueue-protocol-02.txt

[Rahmat M. Samik-Ibrahim]

Interesting
--

http://www.ietf.org/internet-drafts/draft-krebs-gnuqueue-protocol-02.txt

Copyright Statement 
 
   This document is Copyright (C) W. G. Krebs (2000). All Rights 
   Reserved. However, distribution of this memo in its original form is 
   unlimited

Full Copyright Statement 
 
   Copyright (C) W. G. Krebs (2000). All Rights Reserved. 

   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 

   [... standard BCP-9 blah blah blahs...]


-- 
Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org
-- Fuehrerschein, n --- A permit to drive the Fuehrer 

RE: OPES charter proposal again.

[Tomlinson, Gary]

On Wednesday, July 04, 2001 @5:06 PM Michael W. Condry wrote:
>out of interest, did any other groups need to have
>these restrictions?
>At 11:03 PM 7/3/2001 -0700, James P. Salsman wrote:
>>I hope that the latest attempt at the OPES charter is resoundingly
>>rejected by the IESG.
>>
>>If it is not, though, I would suggest these three special requirements
>>for an OPES working group:

This is a most unusual request.  In fact, I have no idea where you are 
coming from.  

>>
>>1. The Security Considerations section could be required to be placed
>>at the front of all OPES drafts, following the legend, "This OPES
>>working group publication is required to have a Security Considerations
>>section that meets certain requirements [cite BCP].  Readers are
>>encouraged to confirm for themselves that the Security Considerations
>>section requirements have been met."
>>

And why would this be?  It is recognized by OPES that security is a 
fundamental issue to be addressed.  Please read the current charter.

>>2. Another section, "Ethics Considerations," could follow immediatly
>>thereafter, and explore the ethical implications of the technology
>>being described, in terms of privacy, disclosure and other terms of
>>service requirments, and impacts upon common carrier feasability.
>>

OPES services MUST be authorized by the party they are being provided 
for.  How can this not be ethical?

>>3. A third section, "Legal Considerations," could survey and cite the
>>laws that could be inadvertently violated by careless implementation
>>or use of the technology described, such as the U.S.'s Electronics
>>Communications Privacy Act.
>>

This one is even more puzzling.  OPES services acting in behalf of clients
MUST be authorized by them.  Such a OPES service may in fact improve privacy

from those over aggressive cookie trackers.  

>>Cheers,
>>James
>
>Michael W. Condry
>Director,  Network Edge Technology

An area many seem to forget about in these diatribes is the Enterprise
(intranets).  These are wholly contained within an Administrative Domain
which
renders most if not all the issues raised above irrelevant.

Sorry for the harsh reply, but this proposal went over my piling on limit.

Gary

Re: OPES charter proposal again.

[Micah Beck]

I would suggest to the advocates of the OPES working group that they
reconsider the modification I suggested to the charter a while ago, and
which generated almost no discussion:

Modify

"Intermediary services provided in this way are not
transparent: They have to be authorized by either the
content requestor or the provider, corresponding to
who the service being provided for."

to read

"Intermediary services provided in this way are not
transparent: They have to be authorized by the provider."

To those who see no reason for such a restriction, I suggest that it might
server to address the sort of reaction you see from James Salsman in the
note below.  If you think that reaction is unreasonable, that won't matter
if it is widely enough held to keep the working group from getting chartered
or establishing consensus on anything.

To those who want a more reasoned response to why this a good proposal, I
offer this:

1. If the transformations being proposed are advantageous to the client and
not harmful to the content provider, then any reasonable content provider
should agree to them.  If the cost of contacting the original content
provider is prohibitive, then the content provider can authorize an agent to
act on their behalf, and that agent can reside in the OPES box.  They can
even issue a blanket authorization, authorizing all transformations
requested by the end user.  The architecture is almost identical to that
being currently proposed, except it is under the control of the content
provider.  The fact that the OPES charter explicitly allows transformations
that are not authorized by the content provider looks suspicous if not
downright dangerous to some people.  Why cut them out unless you think that
they will not want their content transformed?

2. Of courese, the client can capture content from the browser and transform
it locally, or can write their own browser that performs local
transformations (Mozilla is now open sources, after all).  While that is
true, the provisioning of transformations in the network violates a common
assumption among end-users of content that the network is transparent and
that they are recieving content as the provider intended.  It is well
established that end users can do some things with content on a personal
basis (like sharing MP3 files) without fear of prosecution but conspiring
with them to do it within a community is either illegal or immoral,
depending on who you talk to.  Transformation of content in the network
without the authorization of the content provider can be a power tool for
using content in ways never forseen by the content provider.

As I understand it, this proposal satisfies neither the people who want to
create a market for user-directed transformation of content, nor the people
who want to keep all transformations out of the server-to-browser path.  My
questions are these:

1. Would this proposal accomplish a significant part of what the advocates
of an OPES working group are trying to achieve?

2. Would this proposal satisfy the people who are dead set against OPES
because of the danger of transformations that go against the intentions of
the content provider?  Would anyone still find OPES dangerous to content
providers or end users if the charter were modified in this way?

The current discussions on OPES are focusing almost exclusively on iCAP, and
I fear that those who are dead-set against out of fear that it allows
content to be misappropriated may simply dig in their heels since their
fears are not being addressed.  If transformations that are purely
client-directed are really needed, it would be possible to try and extend
the charter to include them later.

Perhaps I am misreading the politics here, and my proposal is either
unnecessary or inadequate.  Perhaps someone could at least explain why.

Micah Beck
Research Associate Professor, University of Tennessee
Chief Scientist, Lokomo Systems

- Original Message -
From: "Michael W. Condry" <[EMAIL PROTECTED]>
To: "James P. Salsman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 04, 2001 8:05 PM
Subject: Re: OPES charter proposal again.


>
> out of interest, did any other groups need to have
> these restrictions?
> At 11:03 PM 7/3/2001 -0700, James P. Salsman wrote:
> >I hope that the latest attempt at the OPES charter is resoundingly
> >rejected by the IESG.
> >
> >If it is not, though, I would suggest these three special requirements
> >for an OPES working group:
> >
> >1. The Security Considerations section could be required to be placed
> >at the front of all OPES drafts, following the legend, "This OPES
> >working group publication is required to have a Security Considerations
> >section that meets certain requirements [cite BCP].  Readers are
> >encouraged to confirm for themselves that the Security Considerations
> >section requirements have been met."
> >
> >2. Another section, "Ethics Considerations," could follow immediatly
> >th

Re: OPES charter proposal again.

[Michael W. Condry]

out of interest, did any other groups need to have
these restrictions?
At 11:03 PM 7/3/2001 -0700, James P. Salsman wrote:
>I hope that the latest attempt at the OPES charter is resoundingly
>rejected by the IESG.
>
>If it is not, though, I would suggest these three special requirements
>for an OPES working group:
>
>1. The Security Considerations section could be required to be placed
>at the front of all OPES drafts, following the legend, "This OPES
>working group publication is required to have a Security Considerations
>section that meets certain requirements [cite BCP].  Readers are
>encouraged to confirm for themselves that the Security Considerations
>section requirements have been met."
>
>2. Another section, "Ethics Considerations," could follow immediatly
>thereafter, and explore the ethical implications of the technology
>being described, in terms of privacy, disclosure and other terms of
>service requirments, and impacts upon common carrier feasability.
>
>3. A third section, "Legal Considerations," could survey and cite the
>laws that could be inadvertently violated by careless implementation
>or use of the technology described, such as the U.S.'s Electronics
>Communications Privacy Act.
>
>Cheers,
>James

Michael W. Condry
Director,  Network Edge Technology

Re: OPES charter proposal again.

[Michael W. Condry]

If the working group wants to endorse iCAP I will discuss this
with ECMA - HOWEVER, team members have made it clear
that an ECMA vs IETF game is not desired. If ECMA honors
the IETF process then they will do that otherwise I doubt
if OPES team members will bother working on
"cleaning up" iCAP as they have been doing recently.

At 04:40 PM 7/3/2001 -0500, Brian E Carpenter wrote:
>"Michael W. Condry" wrote:
> >
> > At 02:45 AM 7/3/2001 +0100, Lloyd Wood wrote:
> > >I do like the 'extend [..] the iCAP protocol without being obliged to
> > >retain any level of compatibility with the current iCAP proposal.'
> > >Fine, since iCAP's just an individual draft -- but isn't extending
> > >without being compatible something only Microsoft is generally
> > >regarded as being capable of doing?
> >
> > That is not the intent. The intent is that the IETF process
> > will be followed with regard to iCAP (not some other organization's
> > process).
>
>Not ECMA's, for example?
>
>   Brian

Michael W. Condry
Director,  Network Edge Technology

Fw: DNSEXT WGLC AXFR-02 SHORT last call

[Jim Fleming]

- Original Message -
From: "Randy Bush" <[EMAIL PROTECTED]>
To: "Jim Fleming" <[EMAIL PROTECTED]>
Sent: Wednesday, July 04, 2001 2:43 PM
Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call


> [EMAIL PROTECTED] is the mailing list for the ietf dnsext wg.  see
>  for the wg
charter.
> messages should be on topics appropriate to the dnsext wg, which are
various
> discussion of the dns protocols or administrivia of the wg itself.  the
list
> is moderated.
>
> calls for papers, announcements of events not directly relevant to the dns
> protocols, etc. are not appropriate.  discussion of problems with
particular
> implementations, announcements of releases, sites' misconfigurations, etc.
> should be done on mailing lists for the particular implementations.
>
> there is a wg for dns operational practice, dnsop, whose charter can be
> found at .
>
> there is a mailing list for discussion of whose implementation is better,
> and why someone else's is broken.  it is [EMAIL PROTECTED]  all
> discussions of such nature should occur there or on /dev/null.  unlike the
> namedroppers list, [EMAIL PROTECTED] is not archived.
>
> discussion of this policy is a topic for the poisson wg.  poisson's
charter
> can be found at .
>
> > From: "Jim Fleming" <[EMAIL PROTECTED]>
> > To: "Paul A Vixie" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> > Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call
> > Date: Wed, 4 Jul 2001 14:40:31 -0500
> >
> > - Original Message -
> > From: "Paul A Vixie" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, July 04, 2001 1:59 PM
> > Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call
> >
> >
> > > > If your implementation is not compliant then you have three choices,
> > > >  1. Convince the working group to change the specification
> > > >  2. Update your incorrect implementation
> > > >  3. Discontinue distribution of non compliant software.
> > >
> > > You forgot one:
> > >
> > >4. Continue distribution of noncompliant software
> > >
> > > (this shall be henceforth be known as the Scorched Earth approach.)
> > >
> >
> > The "toy" IPv4 Internet is a sewer.
> > IPv8 is designed to be a swamp to cover the sewer.
> > IPv16 is the "high-ground"
> >
> > ...good luck in the sewer
> >
> > Jim Fleming
> > http://www.unir.com
> > Mars 128n 128e
> > http://www.unir.com/images/architech.gif
> > http://www.unir.com/images/address.gif
> > http://www.unir.com/images/headers.gif
> > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
> > http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
> > http://www.ietf.org/mail-archive/ietf/Current/msg12213.html
> > http://www.ietf.org/mail-archive/ietf/Current/msg12223.html
> >
> >
> >

Please stop

[Aamir Husain]

It is very sad to see all the crab mails being sent to
this institution of respect which has done so much
good for the Internet community.

I earnestly request all the gentlemen out there to
immediately stop sending irrelevent mails to our
esteemed society.


With warm Regards,
Depmy.

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

this is great

Below is the result of your feedback form.  It was submitted by
 ([EMAIL PROTECTED]) on Wednesday, July 4, 2001 at 03:59:45
---

: For free porn. NO CREDIT CARD NEEDED!!! http://www.geocities.com/unxpexted/index.html";>Click Here 

---

Re: OPES charter proposal again.

[Dave Crocker]

At 11:03 PM 7/3/2001, James P. Salsman wrote:
>I hope that the latest attempt at the OPES charter is resoundingly
>rejected by the IESG.

The key task statement in the opening paragraph of the draft proposal is:

 "define application-level protocols enabling such intermediaries 
to incorporate services that operate on messages transported by HTTP and 
RTP/RTSP."

"Incorporate services" is vague.  Or rather, it says nothing useful.  The 
opening paragraph of a charter is to be widely distributed, to help people 
decide what a working group is doing and whether it is relevant to one's 
own work.

The current proposal language is frankly a Rorschach for anyone with any 
HTTP-related activity that might involve an intermediary.

Later language in the draft do not assuage this fear:

 "protocols to be defined provide a framework for integrating a 
wide range of services".

Specifics (or even examples) are not provided.

Honest.  In spite of considerable experience writing and reading IETF 
charters, I can not tell what problem is to be solved, never mind how.

d/


Addendum  #1:

 Either as an minor irritation, or as a major demonstration of 
deception -- and I can't quite decide which -- the iCAP web page 
 uses the IETF logo in a fashion that can easily be 
taken to imply IETF endorsement for 
.

Addendum #2:

 Isn't an implied promise to integrate HTTP and RTP/RTSP rather 
ambitious?


--
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  fax +1.408.273.6464