for troubleshooting technical issues.
The reasons for moving RFC 1032 from status UNKNOWN to status
HISTORIC are light. Such a move would have a negative impact on
active usage as RFC 3912 does not document the contact point for
problems concerning a domain.
Regards,
-sm
informative than what is
written in the draft.
Status UNKNOWN seems like a fine status to keep, in my opinion.
Status INFORMATIONAL
That's my opinion too.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
, is just policy
requirments (and bad ones) which are NOT IETF business.
The draft makes no mention of policy requirements as the reason for
the change in status. The reply sent by Harald Alverstrand offers a
clearer explanation for this draft.
Regards,
-sm
redirection to that server. The
threat remains.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
in the necessary time. Most people don't meet
either condition.
I agree. Any solution for the type of user you mentioned is only
effective if it is easy for them.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo
with the restrictions
until they experience the drawbacks first-hand.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
that there
is a problem, it's difficult to find consensus as to the solution.
Now you are criticising an architecture document which does not yet
exist.
That was not the intent.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org
networks are reachable?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
establish a
contact. Once that is done, you can use it to validate future
communication you receive from that correspondent.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
but it may be a
hurdle to others if we take into account geographical boundaries or
size of business. Unfortunately, we won't hear the voices of those
facing the disconnect.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman
to be upgraded. There's also the question of abuse which hasn't been explored.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
stage, for
example, when the message is sent to a mailing list. We could get
around that by adding a Sender: field on transmission but then it
would go against RFC 2822 Section 3.6.2.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1
At 22:47 10-09-2007, Lakshminath Dondeti wrote:
Here is the link to nominate: https://tools.ietf.org/group/nomcom/07/nominate
That url brings up a warning in the browser as the SSL certificate is
for *.tools.ietf.org.
Regards,
-sm
___
Ietf
if they do not change the advice given in section 4.
Although this document does not create any new security issues for
the DNS protocol, it may be an issue for users of the service. A
note covering the points you raised could be added under security
considerations.
Regards,
-sm
interoperability in regards to
open source/free software. From a technical point of view, there is
nothing that prevents implementation if the specifications are
available. But then, we are taking a narrowed view of interoperability.
Regards,
-sm
.
Is there a reason why this draft should be on Standards Track?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
at the front page, as long as it's
not too heavy-weight -- the major objection isn't to the news page as
such, but to the increased size of the page *for you personally as a
consumer of the page*
I would prefer tools to be lightweight. Some people are still on slow links.
Regards,
-sm
URI or IM URI and take appropriate action.
Because it doesn't include every URI scheme under the sun? ;-)
No, it's because it doesn't contain a snail mail address to support
legacy communication channels. :-)
Regards,
-sm
___
Ietf mailing list
matter may serve as a wake up call to Africa if
they plan on significantly expanding their network.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
preferring) IPv6
can have downsides. In my case it means the IETF website is
Agreed. However, finding out what works and what doesn't work might
not be an alternative in a production environment as it would have a
significant impact on mail delivery.
Regards,
-sm
. It's more about the legal framework in
which the organization operates.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
to impose a particular
recommendation without any elaboration from the author.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
get together electronically, they have
flame wars. :-)
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf
transitions.
Good question. It would have been better to have the registration
site under *.ietf.org instead of being directed to a third-party
site. It may inspire more confidence.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
http
. The easier fix is for you to reject mail from
@bounces.spamarrest.com. As a bounce probe doesn't always identify
these problematic addresses, it is difficult to unsubscribe them.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman
of people randomly selected from among a set of folks
whose only qualifications are that they want to be on nomcom and they like
traveling to meetings.
The nominating committee is the IETF's version of a democracy (sortition).
Regards,
-sm
___
IETF
would be
treating IPv4 and IPv6 differently.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to mailhost.example.com.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
It's still needed to prevent the A lookup.
It would be needed until IPv6 takes over.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
].
These are not guidelines; they are requirements.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the fallback to the
record if the MX record doesn't exist. The debate has been about
whether IPv6 SMTP clients should use the existence of the MX record
as a test to determine whether the host wishes to receive mail.
Regards,
-sm
___
IETF mailing list
At 13:31 01-04-2008, Robert Moskowitz wrote:
Can't connect to it via ftp.
There seems to be a problem with the FTP service on
ftp.ietf.org. The problem has been reported to the Secretariat.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https
countries. It may be better to
reassess the proposals in the draft especially as it states to be a
framework for increasing email security.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
be on the minds of the silent majority that
follow the IETF mailing lists.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
will be delayed) or at
the request of the
IESG or a relevant Area Director.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
are
judged on their technical merits.
Regards,
-sm
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
, particularly if folks wanted to pursue a community
discussion about a concern with the draft.
Section 1.2 of the draft specifies where the document was being
discussed. I assume that people commenting on the draft would have read that.
Regards,
-sm
. The participants in the WG should be
aware that there will be an IETF-wide last call. You cannot blame
the process if they choose to remain silent instead of taking part in
the last call. Note that letter-writing campaigns in a last call
have been proven to be ineffective.
Regards,
-sm
participants, but they need to be made aware that the IETF does not
exclude such people.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
3675?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
top level
domain names reserved for use in private testing, as examples in
documentation, and the like.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
contexts of public service on behalf of the
Internet community and trustee... for the global Internet
community-- was considered a design feature and a safeguard against
a variety of potential abuses. Obviously the world has changed in
many ways (since then) ...
Regards,
-sm
was
implemented. Can someone point me to that thread?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
as part of
the approved process documents, it shouldn't be used as a formally
approved document.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
mean that there should
be a hard rule which forbids it.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the
ID-Checklist explain the rationale with inline comments. (e.g.,
Editor's note:
or Note in Draft: that can be evaluated by the IESG and the IETF
community along
with the rest of the document.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
and contributors. Does
a company fall within these two categories?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
considered.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to the IETF Tools team, one can compare the two I-Ds by going
to
http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/internet-drafts/draft-rfc-image-files-00.txturl2=http://www.ietf.org/internet-drafts/draft-crocker-rfc-media-00.txt
Regards,
-sm
done, or expected to be done, within the
IETF community.
Given that the RFC Editor is explicitly mentioned in RFC 2026, does
RFC 2606 have to be revised to bring it in line with the proposed structure?
Regards,
-sm
___
Ietf mailing list
Ietf
of the assignment needs to be considered.
Will authors have to seek the permission from the holders, in the
case of domain names (e.g. www.w3.org), before using such domains in RFCs?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
schemas?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
GMT)
doesn't link to the first URL. Refresh if you are still getting a stale copy.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
in picking a header field,
standardizing its format, and so forth.
Implementors will likely pick X-Gateway as you mentioned that header
name in the example. Once people start using specific headers, it's
difficult to depreciate them in favor of some standardized format.
Regards,
-sm
:
The news-to-mail gateway adds an X-* header field to all messages it
generates. The mail-to-news gateway discards any incoming messages
containing this header field.
Would that be an improvement?
Yes, that's better.
Regards,
-sm
-smime-bfibecms-10 is
on the Informational Track whereas it is on the Standards Track.
As there seems to be only one implementation and very little public
discussion about the draft, I don't see why it should be on the
Standards Track.
Regards,
-sm
Specification document(s):
(Note to RFC Editor: the RFC number of this document if approved)
Related information:
none
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi John,
At 09:13 07-11-2008, John Levine wrote:
I think you're talking past each other here. I read SM's message
as adding VBR-Info: to the list of known mail header lines here:
http://www.iana.org/assignments/message-headers/perm-headers.html
Thanks, that's what I meant.
Regards,
-sm
, in
agreement with the IAB, will manage mechanisms for appropriate
technical review of IRTF submissions.
I don't see why there has to be assumptions here. I suggest dropping
the assumes and clearly spell out who is going to manage what.
Regards,
-sm
is part of the IETF stream?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
review of independent submissions.
Likewise, the IRSG, in agreement with the IAB, shall manage
mechanisms for appropriate technical review of IRTF submissions.
That sounds better.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
don't care so much what words we use to say this, but I would like
to see that the ability to make this judgment call is retained. This
is why I like the current text more than the proposed one above.
I agree with you.
Regards,
-sm
___
Ietf mailing list
information disclosure.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
. What do other reviewers find/think/believe/prefer?
In a different message, John mentioned has concluded. That sounds
better as the numbered items are about conclusions reached. My
second preference would be The IESG believes.
Regards,
-sm
FTP EXTENSION ALLOWING IP FORWARDING (NATs)
http://www.ietf.org/internet-drafts/draft-rosenau-ftp-single-port-05.txt
There were some discussion about one of the above I-Ds in Dublin.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https
of this draft may then require the IETF to endorse
Sender-ID. After all, email
As I mentioned before on the mail-vet mailing list, this header is
used to convey results of DomainKeys, DKIM, SPF and Sender-ID
evaluation. It is not an endorsement of a specific evaluation method.
Regards,
-sm
to the sender or else stick to the belief that his/her mail
filtering is perfect and it's up to the sender to jump through hops
to get his/her message through.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
no position regarding the validity or scope of any
Intellectual Property Rights or other rights.
1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05509.html
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman
. If we are changing the
author, then the message should be viewed as a new instantiation of
the message.
Is there a need for Original-Subject and Original-From headers as
defined in this specification?
Please change the reference from RFC2822 to RFC5322.
Regards,
-sm
of features which seem unused because well-known mail clients do
not implement them. I don't see a strong case as there are some mail
clients that implement the feature.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman
meant IESG and
not IETF) stewardship role, I'll point to the fact that the IESG did
not rubber stamp the specification for the proposed header during
their evaluation. The record shows that they raised several
questions about it.
Regards,
-sm
1. http://www.ietf.org/proceedings/07dec/slides
conflict that was observed. Obviously,
it's in their best interests to reach a consensus on what changes are
appropriate instead of trying to publish each document individually
as any individual effort would likely face opposition from the IETF community.
Regards,
-sm
for the current problems with RFC 5378 to be resolved.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
? Not all SMTP
The question I asked was about implementations. I'm at a lost as to
why you see that as recommending coercion.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
was operating within the Standards
Process. Now, I need to hire a lawyer before asserting anything.
Regards,
-sm
P.S. I share the blame because of the comments I posted to the IPR WG.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo
his contribution
than to determine when he was informed that the Note Well has been updated.
Regards,
-sm
1. http://trustee.ietf.org/license-info/
2. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05399.html
3. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05509
has to follow the advice in section 3,
there seems little reason to let it hang around.
If the IESG determines that a WG is OBE, it should say so instead of
creating do not publish rules.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https
accepted assurance group to vouch for them?
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of deployment has been taken into consideration in the design of some
specifications published on the Standards Track.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
was about the impact of your proposed
specification if the technology is widely deployed. My opinion is
based on operational experience and not on market theories.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
not wish or elects to
withhold the rights as he/she does not have a choice in the matter.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of such pre-5378 Material outside the
IETF Standards Process:
That sounds fine.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the choice to discard such messages automatically and I will do so.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
At 11:37 11-02-2009, Tim Polk wrote:
I will rectify the situation this week and request that the TLS WG
review
the document to gauge interest in this area. I would be delighted to
Are you requesting that the TLS WG review an Internet-Draft that
expired in December 2006?
Regards,
-sm
of the message
itself. The author of the draft mentions that rather than create a
separate header field for each class of solution, this proposal
groups them both into a single header field.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https
Trust Provisions Section
6.b License Notice from 10 Nov 2008 rather than the newer Notice from
12 Feb 2009. Both versions are accepted up to the end of March 2009;
after that you'll need to use the 12 Feb 2009 Notice.
The warning is not because of the pre 5378 workaround.
Regards,
-sm
[RFC2505], although the
address can be spoofed.
As the focus of the draft is email architecture, this doesn't fit
under security considerations.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
or for delivery.
The draft says that a relay can modify message content representation
whereas RFC 5321 says that a relay does not do any modification to
the message data other than adding trace information.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
the people listed in the author field for these documents
make the choice
4. The author of the draft makes a choice based on the Last Call comments
5. Leave it to the IESG to decide
6. Ignore the question
Regards,
-sm
___
Ietf mailing list
Ietf
a
standard. The Status of This Memo which is prominently displayed
on the first page of the RFC mentions that:
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Regards,
-sm
*not* an IETF standard of any kind.
You said it better than me.
There was a mistake in my previous message. A not was omitted. The
correct sentence is:
Publication as an Experimental RFC does not make a document a standard.
Regards,
-sm
___
Ietf mailing
but there is one thing I know. As long as the tradition is
preserved, the Internet community will have a mechanism to publish
technical information.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
At 02:27 11-03-2009, Alessandro Vesely wrote:
Does that include legal threats?
No. Harmful here should be viewed as harmful to the work of a
Working Group or if the document proposes to use free bits for a
purpose which is contrary to the meaning the standard defines.
Regards,
-sm
expires on
September 9, 2009. There is a Pre-5378 Material Disclaimer section
at the end of the I-D.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
problem to solve as there is the
existing workaround. Unless there is a compelling reason for the
first choice, I don't see a need to spend more time on this issue.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo
-social behavior as that only fuels the
argument. It might also send the wrong message.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
address to which example.com resolves
to. There isn't any mail service listening for SMTP connections at
that IP address nowadays.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
At 06:49 11-04-2009, Alexandru Petrescu wrote:
Sorry I missed it, but what was the April's Fool draft this year?
You have the choice between RFC 5513 and RFC 5514.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman
1 - 100 of 701 matches
Mail list logo
