Could be an app that put you in the queue and used your
laptop/tablet/smartphone microphone to get the audio.
On Tuesday, August 6, 2013, Michael Richardson wrote:
Dave Crocker d...@dcrocker.net javascript:; wrote:
An entirely different approach would be to have all speakers make a
Following a request to look at this document, and with only a cursory look
at the archives, I'm confused.
The note is always intended to be included in the document itself, right?
Is this change designed to compel, as opposed to request, the RFC Editor to
include the note?
If the answer to
Yes, I understand, this only applies to the Independent Submission stream.
We ask the IESG to review these documents, and that review is technical.
I don't think it is appropriate for an editor to make a judgment of whether
a technical note is, or is not appropriate to be included in a document.
I like this thought quite a bit.
I see the RFID thing as being a good idea in concept, and we need to work
through how to use it most effectively.
In this specific case, I think we treat the tag as an identifier, and allow
the user to decide what the data associated with this identifier should
Minor nit on the last part:
When the keys are randomly generated and of sufficient length,
these attacks do not obtain
obtain doesn't work. Either do not succeed or generally do not
succeed or even usually fail.
Brian
-Original Message-
From: Gonzalo Camarillo [mailto:[EMAIL
On most devices of interest, this is a non issue; they are small embedded
devices, like phones.
For other situations, for example a sip softclient running on a laptop, we
will specify an api on the O/S the application is running. The api will
front end a set of Location Configuration Protocols
on the O/S the application is running
Who is we, geopriv?
Guy Caron
-Message d'origine-
De : Brian Rosen [mailto:[EMAIL PROTECTED]
Envoyé : 25 avril 2007 14:29
À : 'Hallam-Baker, Phillip'; 'John Schnizlein'; 'David W. Hankins'
Cc : 'GEOPRIV WG'; ietf@ietf.org
Objet : RE: [Geopriv
deployment model.
Brian
-Original Message-
From: Dawson, Martin [mailto:[EMAIL PROTECTED]
Sent: Friday, April 20, 2007 9:03 AM
To: Brian E Carpenter; Hannes Tschofenig
Cc: Brian Rosen; GEOPRIV WG; ietf@ietf.org; Allison Mankin; John
Schnizlein
Subject: RE: [Geopriv] Confirmation
The cable systems use the MAC address of the DOCSIS modem to determine which
subscriber is asking for location. It's not perfect, because it is possible
to move a DOCSIS cablemodem from one house to another within some area
(often the service area of the CMTS, but in many systems, less than
PROTECTED]
Sent: Friday, April 20, 2007 10:14 AM
To: Brian Rosen
Cc: 'Brian E Carpenter'; 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org;
'Allison Mankin'; 'John Schnizlein'
Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Brian Rosen wrote:
The cable systems use the MAC
In the example you gave the Hilton is EXACTLY the network that MUST give you
your location, and Verisign, if they tried, would give a valid, but very
wrong location.
That is the point of using DHCP for location, you need the closest possible
server to get the right location. You need a server
However, what this subthread demonstrates is
that they were conceptually an incremental change, not a giant,
discontinuous, intellectual leap.
I thought we all knew that.
Oh, I agree, we knew that. There are very, very few discontinuous
intellectual leaps in our part of the universe. It's
If you squint hard enough, everything has already been invented. Telegraph
operators had a form of presence if you squint hard enough.
Presence is a continuously updated 'display' of a set of other people's
status. Finger didn't do that. Yeah, you COULD have used the mechanism to
implement a
It may have changed, but when Marconi sponsored an IETF, the budget was
about $250K for the network, terminal room, help desk, hospitality desk,
t-shirts and the difference between expense and receipts for the social
(hint: most socials cost more than the $25-30 that is charged). No
equipment was
I've actually been successful at arguing something like the opposite of
this.
Many corporations now assert this silly little hunk of text at the end of
every message claiming the email is private and such. A typical one is:
This message and any attachments to it may contain PROPRIETARY AND
I believe if the community does not have confidence that the protocol will
actually work on the Internet, then we are experimenting. I think this
definition would cover a number of protocols we would now consider for
Proposed Standard (rather than Informational), and pushes us back towards
PROTECTED]
Sent: Monday, January 09, 2006 11:37 PM
To: Brian Rosen
Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs
On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
Any format can be used for any purpose, but it might
with
meta-data.
Brian
-Original Message-
From: Theodore Ts'o [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 8:58 AM
To: Brian Rosen
Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs
On Tue, Jan 10, 2006 at 08:09
sorry, couldn't help it
You mean, like xml?
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 8:53 AM
To: [EMAIL PROTECTED]
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
...
What we are seeing is increasing use of fully
:[EMAIL PROTECTED] On Behalf Of Paul
Hoffman
Sent: Tuesday, January 10, 2006 11:15 AM
To: ietf@ietf.org
Subject: RE: Alternative formats for IDs
At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
Do you have any idea how painful it is to build any kind of product that
has
good management simply because
So, the problem you are citing is the issue that you want to harvest data
out of the ID or RFC. That's common now, and getting more common. You then
immediately move to say ASCII is the right output format because it makes
harvesting the data you want easy.
Well, probably not as easy as
This
On the other hand, it does appear that the availability of ASCII
support as a common denominator is decreasing over time. As has been
observed, some software vendors seem to go out of their way to make
simple ASCII hard to use. So there is increasing pressure to find
a (truly) better
I notice that we have stopped being interested in running code.
I think that is to our community's detriment.
If two groups are arguing with one another, and one has implemented code and
the other has not, I think we would give great weight to the running code.
I don't see that happening. This
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
I read the first draft of this document, and wondered:
Does this propose to change IETF behavior on list management, so that the
name of the list (usually same as working group) is not put in the Subject:
using the feature of mailman that does this?
When it was just a draft, it was just
I don't have any comment on the issue of language tags, but speaking as a
reasonably avid ABNF hacker, I agree with Sam, and would not want to
establish a convention that ABNF in IETF RFCs is expected to be precise.
One MUST read the text to understand what the limits of the syntax are.
This is
You guys don't have a problem with the defensive suspension/no first use
clauses, do you?
Is there a preferred wording for it?
Brian
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Eric S. Raymond
Sent: Wednesday, October 13, 2004 10:56 PM
To: Sam
for an example.
Brian
-Original Message-
From: RL 'Bob' Morgan [mailto:[EMAIL PROTECTED]
Sent: Friday, October 15, 2004 1:28 PM
To: Brian Rosen
Cc: IETF
Subject: RE: Shuffle those deck chairs!
On Fri, 15 Oct 2004, Brian Rosen wrote:
You guys don't have a problem
28 matches
Mail list logo
