u
should really give it up already trying to convince people SSP will
crack the earth.
FWIW, NO SSP == NO DKIM. Its worth less overhead.
That said, Have a happy new year. :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
MTP IPv6/4 technical spec effort.
Thanks
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Tony Hansen wrote:
>
>
>
> During the second last call for rfc2821bis, there has been much
> discussion of how the "implicit MX" handling is
eds of operators say something else, that the implementor is placed in
> an awkward position.
+1000
Thank you for seeing this Keith.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
h, Solid Matrix Technologies
Inc, John Levine and the IETG.
With that said, pursuant to the process detailed in RFC-2026 section 6.5,
I appeal the IETF and IAB, the ASRG chair(s) decision: "Revocation of
posting privileges for Hector Santos" for the following reasons:
a) From the onset, spec
The IETF should be leading the charge for easy to use, multi-device
readiness cyberspacing virtual meeting places, including better
electronic groupware collaboration tools, etc. It is undoubtedly and
inevitably the "Achilles' Heel" for the IETF Meeting. So the IETF
needs to embrace it now, bi
The IETF should be leading the charge for easy to use, multi-device
readiness cyberspacing virtual meeting places, including better
electronic groupware collaboration tools, etc. It is undoubtedly and
inevitably the "Achilles' Heel" for the IETF Meeting. So the IETF
needs to embrace it now, big t
+1
John C Klensin wrote:
--On Tuesday, November 27, 2012 13:00 -0500 Barry Leiba
wrote:
...
So here's my question:
Does the community want us to push back on those situations?
Does the community believe that the real IETF work is done on
the mailing lists, and not in the face-to-face meeting
This proposal sounds interesting but couldn't it run into conflicts
when there are competition in running code? Who's running code do
you fast track? How does it apply in the protocol updates area, i.e.
BIS work?
This proposal and thread, similar to the recent others, all seem to be
lookin
Melinda Shore wrote:
On 12/1/12 2:21 PM, Stephen Farrell wrote:
My reluctance to get into this is based on an opinion that process
change proposals with more words attached tend to just not happen,
so fewer words is better.
I think that's actually a pretty terrible reason. The goal is
not to
Melinda Shore wrote:
On 12/9/12 10:43 AM, S Moonesamy wrote:
I would like to ask you to pick the three points from Section 2 (
http://tools.ietf.org/html/draft-moonesamy-mail-list-protocol-00 ) which
you consider as helpful to facilitate mailing list discussion and send
them to me off-list. I'l
+1.
I think it is important that we have communications tools for
documenting strong minimum protocol requirements and we only have
RFC2119 to make that possible.
Yet, we need to be careful where the lack of RFC2119 upper case
wordings can be used to leverage an argument for relaxation of
e
Scott Brim wrote:
It's a communication problem. If you want your audience to understand
exactly what you're saying, and implement along very specific lines, you
need to tell them in a way they understand.
+1
Personally I prefer a quieter approach, but I've been told that
these days one MUS
Keep in mind only a STD is a "real" standard. A RFC is still only a
recommendation, a guideline. What makes it a "pseudo-standard" is
the # of implementations, how wide spread it is and foremost IMO, how
much embedded it is so that a change has a negative impact. At that
point, an RFC not ha
Thanks Carsten for your explanations. As having experience with both
styles of programming as you describe and also interpretive vs p-code
vs static compiler writing for our servers and clients, it would seem
to me that if the both syntaxes are possible, then the solution is
more implementator
Maybe the survey to be done is a review of all the RFC, STD and see
which ones
- had a great abstract and introduction,
- had the better writing styles
- had the least endorsement resistance
- progress faster than most,
- had the most implementators,
- with least support/questions need to be ask
I have two concerns and comments:
- How will success or failure be measured? Number of appeal increases
or lesser amount? I have a concern that once this door is open, there
will be increase appeals and also apathy of outcomes. There should be
a statement of what sort of problems or issues
There was a mechancal reason for both and not just an EOL (End of Line)
concept. As you point out, it was the original way to get an emulation of BOLD
characters on print devices. You control the print head and when this
emulation moved to 80x25 screens, the cursor was the carriage head. Some
- Original Message -
From: "Dave Crocker"
To: "Sam Hartman"
Cc: "Abdussalam Baryun" ; "ietf" ;
"Lixia Zhang"
Sent: Sunday, February 03, 2013 1:38 PM
Subject: Re: History of protocol discussion or process in WG
> What I think /is/ possible, however, is to establish a "history of"
>
Notice 4144 has no acknowledgements except for the RFC editor sponsorship. :)
Most I see is common sense, but my view, in my somewhat limited work areas I
have participating in, it doesn't matter if the editor/author doesn't like you.
I guess that would be the exception. I think overall 4144 do
Not to oversimplify the problem or the pursuit for a solution, I think
there are some possible simple, but perhaps not practical, solutions to
the concerns you cite.
- Faster Reviews, Resolutions by external people, i.e. IESG or a new
technical review group specifically for this purpose. When
+1
I saw a small mission statement in this post, good start. Perhaps an
"official" mission statement for the new incoming chair. Take it slow.
Don't need to see a "blog of the day!"
On 2/22/2013 7:35 AM, IETF Chair wrote:
Jari has created a blog as an experiment to see if would be possibl
Hi, with a quick review, and many comments and points, I think the one
single part that I would have some questions about is in the intro:
The guidance provided in
this document is generic and can be used to inform the design of any
protocol to be used anywhere in the world, without ref
Its not really orthogonal if you are seeking a feature list. Will it be
out-sourced, open source or in-house developed?
That's the dilemma with most older establishments that do not wish to provide less
support for its long time "customers" but need to also migrate and provide
other methods a
l ethical
design considerations, this should be one of the tenets of the document,
in my view. Recognized ownership has a very vital effect on what a
protocol may|can|should offer or not offer as to not open Pandora's box.
--
HLS
On 2/24/2013 2:23 PM, Hannes Tschofenig wrote:
Hi Hector,
2/25/2013 3:01 PM, Alissa Cooper wrote:
Hi Hector,
Just to clarify, do you mean ownership of personal data? Or something else?
Thanks,
Alissa
On Feb 25, 2013, at 2:55 PM, Hector Santos wrote:
Hi,
Related to your question, if it wasn't done already, I think there is one item to consider
f including that presumption here, as it leads down the slippery
"rights vs. harms" slope pretty quickly, and we've managed to avoid that
altogether in this document so far.
Alissa
On Feb 25, 2013, at 3:26 PM, Hector Santos wrote:
Hi, I would think both - ownership of the &qu
not trump "good ideas" especially when decided by monopolized groups as
indicated above. In any case, I think the Rough Consensus tool should
be reviewed. I believe Pete Resnick is touching base with how Rough
Consensus is used in his I-D.
That is it for now, if not done. Thank you
One item to consider is to lower the work load of the AD, in particular
in reviewing docs towards of the end of projects. Issues and dilemmas
are piled on. I think one approach to lowering appeals, for example,
is to address unresolved delicate WG issues much faster, in particular
the tough
Speaking as a successful by-product of the american Affirmative Action
and Equal Opportunities programs of the 70s and early 80s, I would
suggest the IETF needs to work two small baby steps:
- Improving its Marketing,
- What is its products?
- What will attract all/any groups?
-
As a minority raised thru the corporate rank, as stated below I think it
is offensive too and unfair to historical facts. But overall, I think it
is just the wrong choice of words. All it could suggest is that there
are more different views and experiences in the "synergistic" effect of
final
+1
There lies the fine line of conflict of interest that I believe the IETF
has done a tremendous job in keeping in control with diverse disciplines
and philosophies well considered. The RFC format by definition, its
style, the open WGs, is all geared towards diverse audiences.
On 3/12/2013
Anything along the lines of "mentoring" the virtual world of IETF
participants? :)
Mr. Klensin, if it wasn't for you, I would of probably lost interest in
the IETF long ago. You have reached out and assisted in more ways you
should be made aware it was very much needed and welcomed. Thank you
On 3/20/2013 3:18 PM, Eric Burger wrote:
> How much is the concentration of corporate participation in
> the IETF a result of market forces, like consolidation and
> bankruptcy, as opposed to nefarious forces, like a company
> hiring all of the I* leadership? We have mechanisms to deal
> with the
+1. My view as well. I will add I think it generally means there will a
problem in a WG if an AUTHOR has issues with its WG participants, enough
to a point he/she begins to ignore them - despite all the input they
provided, included the indirect ones that help mold others to think and
chime in
On 3/25/2013 12:17 PM, Scott Brim wrote:
On 03/25/13 11:54, "John C Klensin" allegedly wrote:
So perhaps a little more guidance to authors and WGs about
acknowledgments would be in order.
or a statement that acknowledgments is not a required section and not
subject to IETF guidance.
or i
Interesting proposal. I suggest perhaps a different "Contributions"
section related to IPR considerations, including also good for open
source/public domain information.
For me, this would be a quick/goto read item after reading a new I-D
abstract of interest.
Good idea.
--
HLS
On 3/25/
Hi Doug,
On 3/28/2013 2:13 PM, Douglas Otis wrote:
Dear IETF,
In response to various strategies to reject IPv6 email lacking either DKIM
or SPF, the non-negotiated approach suggests far greater review is needed.
Whats the difference with IPv6 connections? Should it matter? Does it
matter?
Hi Doug,
This sounds urgent. I am not seeing this urgency, but maybe we just
have it under control.
Another side question Doug, is this an application-level based
filtering? Can one be authenticated lets say for SMTP but not WEB?
Is the filtering applied across all protocols? Is it the IP
Good points Dave.
However, I would suggest that having tighter controls on the transport
practice, e.g.; SMTP handshaking compliancy, following and honoring
exclusive domain published policies, does help minimize support cost.
--
HLS
On 3/30/2013 7:46 PM, Dave Crocker wrote:
On 3/30/2013 7
I believe it should also offer its own membership
and provide IETF.ORG email accounts as well. :)
--
Hector Santos, CTO/CEO
Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: "Ted Lemon"
To: "Dean Willis"
Cc: ; "O'Reirdan
Hi Abdusalam,
You should consider all APRIL 1 published I-D as "SPAM" and the
electronic mail follow ups generated in the IETF list as more wasted
bandwidth, time and spam. We have too much time in our hands, boredom
for many, and even more wasted time if we spend time reading it - so in
th
On 4/6/2013 11:57 AM, Scott Brim wrote:
On 04/06/13 11:52, Hector Santos allegedly wrote:
Hi Abdusalam,
You should consider all APRIL 1 published I-D as "SPAM" and the
electronic mail follow ups generated in the IETF list as more wasted
bandwidth, time and spam. We have too much t
This is one of those DPEP (Diversity Problem Entry Point) arising from
globalization, April 1 HRC (Humor Recognition Culture) differences,
IETF "stalization" and the growth of I-D submissions. I suggest there
is a direct correlation among these factors with the end goal efficacy
of the submi
I don't have the same overall feeling that its less reliable.
I believe it is 100% reliable when it comes to the "good"
communications, the serious stuff, the work, business communications.
Those get through and more importantly, above all, when there is a
problem, good people complain, any em
On 4/19/2013 2:13 PM, Ted Hardie wrote:
> ...
>
There are other methods that may well be better than the two Suresh and I
discussed, but I put these forward as a potentially concrete step that may
help those struggling with this to understand that the end result of this
need not be quotas.
If anyone wishes to see one aspect of what is wrong with IETF Diversity,
then see whats going on in SPF BIS WG where a key IETF cog essentially
attempts to shutdown discussions and communications, attacks posters
which by my estimate were making progress.
Progress is a status quo - DON'T CHANG
The problem I have is not so much with the decision to deprecate SPF
rrtype, it will remove this particular SPF protocol dual SPF/TXT call
overhead in the network, but more so about what it says for future
applications.
There will no incentive to design DNS applications with specific types,
o
resolve, then please accept my apology.
Sincerely,
Hector Santos
On 5/1/2013 9:44 AM, Pete Resnick wrote:
On 4/30/13 7:45 PM, Sam Hartman wrote:
So my personal opinion is that this is a valid discussion to be having
even if we're having it again in IETF LC.
Folks,
This document is *not*
, in their various IETF protocol interest areas.
The structure of this questionnaire will be important to be successful
and beneficial.
Sincerely,
Hector Santos
On 5/3/2013 10:32 AM, Thomas Narten wrote:
"Adrian Farrel" writes:
Well said, Thomas.
Two concrete suggestions:
On 5/5/2013 11:58 AM, S Moonesamy wrote:
Hi Mark,
At 15:57 04-05-2013, Mark Andrews wrote:
The publisher can choose to interoperate with everyone by publishing
both.
The client side can choose to interoperate with everyone by looking
for both.
Both side can choose their level of interoperabil
M overview
(RFC5585) informational publications. Perhaps some update in the future
can correct this design and market inconsistency and explicitly provide
knowledge of the alternative frameworks available for DKIM.
--
Hector Santos, CTO
Santronics Software, Inc.
ommendation outcomes from the Diversity Design Team.
Thank You
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
On 6/19/2013 11:15 AM, Dave Crocker wrote:
On 6/19/2013 8:08 AM, Peter Saint-Andre wrote:
On 6/19/13 8:32 AM, Dave Crocker wrote:
On 6/19/2013 5:35 AM, Dave Cridland wrote:
These are valid points. For a long time, I used a public forum support
reporter for our support process which categorized daily and hourly
messaging patterns, hottest threads and topics and reply efficiency
concepts. Basically to see how many messages were replied to in general
and how many wer
Hi,
I think there are far too many debates on RFC2119 semantics and I think
it can be reduced by focusing on better technical protocol writing
skills. A simple recommendation to always include (if possible) a
Minimum Requirements table or section can go a long way in removing
ambiguity. Som
On 6/24/2013 8:39 AM, John C Klensin wrote:
--On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker
wrote:
They are not synonyms
Lets go back to 1980:
Implementations SHOULD support DES
vs
RECOMMENDED encryption algorithms: DES, IDEA
Actually, that is the point. The usage above, alth
I want to know more what it translates to as a technical specification
for CODING. To me, it means this:
o Authorization Lift Time
[X] Send Notification
Time to send: __4__ mins (default)
The problem as I experienced thus far is whether one MUST IMPLEMENT this
protocol feat
Sounds like an never ending loop. 2119 is an RFC too and thus written in
"RFCish" as well.
To me, it only matters in terms of implementation - should we waste time
and money on implementing a SHOULD/RECOMMENDED feature? Is it required
to be coded? Can it be delayed, for version 2.0? Is it r
ou find out that your users tend
to take coffee breaks that last that long.
On Jun 25, 2013, at 8:13 PM, Hector Santos wrote:
I want to know more what it translates to as a technical specification for
CODING. To me, it means this:
o Authorization Lift Time
[X] Send Notification
What language, OS? There are plenty of rich hashing/encrypting C/C++
libraries out there. Windows has CAPI, even OPENSSL has these libraries.
On 6/27/2013 11:49 AM, Dearlove, Christopher (UK) wrote:
RFC 6234 contains, embedded in it, code to implement various functions,
including SHA-2.
Extr
Ok, other than time, it should be easy to extract, clean up and cross
your fingers that it compiles with your favorite C compiler. But I
would write to the authors to get the original source. Or google:
C source crypto libraries API hashing functions
among the first hit:
http://www.crypt
I believe this is all part of improving the IETF Electronic Diversity
picture. Just like we have to deal with greater people personal
globalization diversity issues, there is also greater technology and
legal diversity issues to deal with. So many tools, so many languages,
so many OSes, so many
insight" if
added to the MLM I-D would be very informative to readers of the
document which would include MLM developer considering all the DKIM
incompatibility issues.
--
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf
dicussion leading up to the wglc. If it's really
inapropiate that's cool but I'm frankly not convinced.
I'm OK if there's consensus not to change it, but the wider scope of
IETF LC and cross-area review is exactly to catch things t
ut the incompatibilities - the "bad". In that vain, we have
a form of "whitelisting."
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hector Santos wrote:
Hector Santos wrote:
The document editor and others believe this is a MLM BUG. It could
be, but we don't know if its really an normal attempt to add HEADER
text that was empty:
Create List Message for Distribution:
Body = EMPTY;
Body += Appen
ement that conflicts
with these goals by telling receivers they MUST (not a MAY) to mind
their own bee's wax if they see an unexpected, unsolicited, unknown,
unauthorized non-first party DKIM signed mail when the author domain
may have a policy that says "Thats a NO NO"
ust a relative few networks or broadband
providers, but there are many software vendors, free, commercial or
otherwise that need to change their software across the board; SMTP,
FTP, NNTP, IMAP, POP3 etc.
The bottom line: unless I am force to support IPv6, stack or no stack,
the investment required
orate identity or not. I guess it all
depends how much of a hard ass is his boss, employer or their chief
counsel. You might find if the IETF is making a fuss, they may ask
the employee to just not participate - lurk, but don't post.
--
Hector Santos, CTO
h
g extreme concern about a draft because it does , I will
overlook your objections because it doesn't do that.") and move on.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ie
ially mobile and
wireless networks, the less overhead the better.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
, please feel free to contact me, or submit
to ietf-action.
Thank you,
Glen
Glen Barney
IT Director
AMS (IETF Secretariat)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Hector Santos, CTO
http://www.santronics.com
also is authorized IETF.ORG as a valid 3rd party
signer for the ISDG.NET domain. This is done by adding ADSP/ATPS
record using this wizard:
http://www.winserver.com/public/wcadsp/wcadsp.wct
Hector Santos wrote:
Cool beans. Message as verified here. The good thing is that it
finally
eeds a copy of the same
trust tables. DKIM is a protocol that requires Batteries in order to
work and everyone must use the same batteries.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf
, and even then, most people in our market
don't understand what utility it offers them. At present, they
believe the "new badge" will help them look better, but there is no
real evidence that it does anything for them.
--
Hector Santos, CTO
http://www.santronics.com
but some big email providers are
currently playing with the idea.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf
lost of policy allowed the
anonymous abuse of these domains to continue.
The issue is straight forward, either resigners support signing
controls or not. Obviously the latter was the easy way for THEM but it
didn't solve the problem. No matter way a policy concept is required.
--
Hec
f the message.
What question is that? Is the question this?
Do author domains have any say on who signs for them
and who/what is considered unauthorized signatures
versus authorized resigning?
Anyway, thanks for your comments.
--
Hector Santos, CTO
http://www.
d never
existed in the first place as a charter item, when in fact, it is
still today a WG charter item.
Very odd.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
DRAFT IETF WORKING GROUP CHARTER
14 Oct 2005
Domain Keys Identified Message (DKIM)
CHAIRS:
T
and restricting resigning.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
oes not get followed 100%.
I guess, if anything, if we are going to allow for faster maturity, we
probably need some guidelines (if not already in place) in how non-WG
RFC productions could influence a current WG.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
R
ntial interoperability issues with submission
downlinks (members) with DKIM security support.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
't say and
quite maybe it was just an exceptional experience and not the norm.
But I believe a watchdog for these type of possibilities will help.
--
Hector Santos, CTO
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
useful information,
but most do not. Its one the first things I look for.
I was going to suggest the same for an RFC, but it could be the WG was
closed down by this time.
Just a thought if it makes sense.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
a new I-D (01?) submission. But then again, I can imagine some that
don't wish to expose this for whatever reason, perhaps to keep the
"team" light (and private) until they feel its ready public work - or
not.
--
Hector Santos, CTO
http://www.santronics.com
Dave CROCKER wrote:
. Those who thinks it benefits readers will add the
info when possible. Those who don't, well, won't.
Not a big deal.
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector
Santos
Sent: Thursday, August 04,
word-smithing to make corrections. Again, if you wish, I can give you
an example off-list to see why questions like these can help.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
d have to go through. Engineers must
have complete faith in implementation reports.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
SM wrote:
This is not an exercise we should have to go through. Engineers must
have complete faith in implementation reports.
Faith-based engineering and reality are mutually exclusive. :-)
Touche!
--
Hector Santos, CTO
http://www.santronics.com
r - you make it optional. Throwing it away will invite
support issues. :)
I said more than I wanted to, but its just my opinion.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
on and has
access to the list membership database, it can do customize payload
per member.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
IETF Methods
for offline users to achieve this - IMAP, NNTP and LIST-ID sorting,
and a new DKIM standard that this kludge conflicts with.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf
would be unfortunate -
nay, negligent - to make a decision on the matter without due discussion,
debate and documentation.
Nick
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Hector Santos, CTO
http
de. If anything, the two-maturity level proposal should
increase the engineering expertise and scrutiny requirements for
reviewers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
did not
consider yet.
Portzamparc
BTW I am not French, I am Breton!
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Since
erely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
iately adjacent addresses take the
normal path?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Sincerely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
hat imply the IETF is now downgraded, in debt and can not be
trusted?
All rhetorical questions. After all, they did "Invent" it. It should
be free to the IETF. :)
Just consider there are some in the DKIM arena who wanted for the x=
expiration tag to be deprecated and removed.
of reporting the theft as soon as it is discovered.
Adam Novak wrote:
On Fri, Aug 26, 2011 at 1:13 PM, Hector Santos wrote:
Makes you wonder. Why is the concept of expiration required? �Did the IETF
expire, die? �Did its value as an Organization go down and only valid on a
year to year basis
ing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Sincerely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ntinues to amaze me.
--
Sincerely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
1 - 100 of 170 matches
Mail list logo
