by the time layer 7 is reached, there is only one address to
be concerned about... or should be. if the library your
thinking of tests reachability, then you have moved the routing
function into the host - which is a much larger problem space.
DISCOVER, unlike QUERY, is designed to deal
Spencer Dawkins wrote:
Hi, Alexey,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you
Hi Joel,
Thanks for forwarding the below - it helps me in understanding the
process. I am not sure whether I am supposed to respond or not on the
comments you provided, but it cannot hurt - so I will do my best. If I
need to provide those comments to a larger forum, or in a different
forum -
Barbara and all,
Why only 4 root servers?
Regards,
Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
Obedience of the law is the greatest freedom -
Abraham Lincoln
Credit should go with the performance of duty and not with what is
very often the accident of glory -
On 6 jan 2008, at 22:00, Brian E Carpenter wrote:
The library
I'm thinking of would also have to handle reachability
checking - and as John said, would ideally also be stateful
to avoid repeating the same timeouts.
I don't think the thing that we need most in this area is a library. I
did
On Fri, 4 Jan 2008, John C Klensin wrote:
However, there is also a rule that, if no MX records are present at a
particular node, the mail system looks for an A RR at the same node and
treats it as if its label appeared with an MX preference of 0. That
default does not apply to records,
Tony Finch wrote:
On Fri, 4 Jan 2008, John C Klensin wrote:
However, there is also a rule that, if no MX records are present at a
particular node, the mail system looks for an A RR at the same node and
treats it as if its label appeared with an MX preference of 0. That
default does not apply
On Fri, 4 Jan 2008, John C Klensin wrote:
On Friday, 04 January, 2008 12:01 -0800 Bill Manning [EMAIL PROTECTED]
wrote:
The general answer when needing to communicate between similar
applications that run on different address families has traditionally
been the application layer gateway
On Mon, 7 Jan 2008, Jeroen Massar wrote:
'a' 'b' are both separate MX's. As such according to the above pseudo-code,
which I deduced from the RFC, whenever 'a' is contactable and you can get a
response from it, you should honor that response. Thus if you contact 'a' and
it replies with a 450
On Fri, 4 Jan 2008, John C Klensin wrote:
There are no MX rules at all about which address must be tried first and
some handwaving in RFC 2821 about how many addresses at a given
preference level need to be tried at all.
In practice MTAs often randomise host addresses, ignoring the
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
At 08:14 06-01-2008, Iljitsch van Beijnum wrote:
Not sure what you mean here by SMTP clients... Would that be client
computers such as the one I'm typing this message on? But those don't
look at MX records, unless I'm very much mistaken.
What you are using to send this message is known as a
Did you file a bug on postifx?
Jeroen Massar wrote:
--
Franck Martin
ICT Specialist
[EMAIL PROTECTED]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320
Toute connaissance est une reponse a une question G.Bachelard
signature.asc
Description: OpenPGP
On 2008-01-07 19:50, [EMAIL PROTECTED] wrote:
Brian E Carpenter wrote:
As Phill H-B has implied more than once, there's scope
for a library on top of the socket API that takes care
of this once and for all. Does anyone have such a library?
Some TCP/IP stacks include this kind of API:
Tony Finch wrote:
On Fri, 4 Jan 2008, John C Klensin wrote:
On Friday, 04 January, 2008 12:01 -0800 Bill Manning [EMAIL PROTECTED] wrote:
The general answer when needing to communicate between similar
applications that run on different address families has traditionally
been the application
John C Klensin wrote:
I'd make a further distinction and claim that even many email
gateways don't rise to the level (or sink to the depths) of what
we usually think about as ALGs. First of all, I would contend
that an SMTP system that accepts an SMTP-and-MIME conformant
message that arrives
Basic abstract of the e-mail:
In RFC 1183, an experimental DNS RR type is defined called the Route
Through (RT) RR. Although not its original purpose, could this be
expanded and used to ease the IPv4 to IPv6 transition?
---
A simple state table gives us 9 possibilities:
# | Endpoint A |
Willie Gillespie wrote:
snip
So, concerning Case #3 and Case #7, which is basically a IPv4 host on
one end and a IPv6 host on the other:
If a IPv6-only host wants to connect to a IPv4-only host, could an RT
record be used to point the IPv6 machine to a suitable IPv6-to-IPv4
gateway?
*
On Mon, 7 Jan 2008, Dave Crocker wrote:
Tony Finch wrote:
MTAs *are* ALGs.
(Uh Oh.)
Nope.
Sorry, I should have been clear that I was talking about practice rather
than architecture.
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH
The IESG has received a request from an individual submitter to consider
the following document:
- 'Diameter Policy Processing Application '
draft-brenner-dime-peem-01.txt as an Informational RFC
The document asks for the assignment of a Diameter Command Code to be
used in a vendor-specific
The IESG has received a request from an individual submitter to consider
the following document:
- 'Unicode Format for Network Interchange '
draft-klensin-net-utf8-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
A new Request for Comments is now available in online RFC libraries.
RFC 5069
Title: Security Threats and Requirements for
Emergency Call Marking and Mapping
Author: T. Taylor, Ed.,
H. Tschofenig, H.
A new Request for Comments is now available in online RFC libraries.
RFC 5089
Title: IS-IS Protocol Extensions for Path
Computation Element (PCE) Discovery
Author: JL. Le Roux, Ed.,
JP. Vasseur, Ed.,
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Session Initiation Protocol (SIP) P-Served-User Private-Header
(P-Header) '
draft-vanelburg-sipping-served-user-04.txt as an Informational RFC
The IESG plans to make a decision in the
A new Request for Comments is now available in online RFC libraries.
RFC 5031
Title: A Uniform Resource Name (URN)
for Emergency and Other Well-Known Services
Author: H. Schulzrinne
Status: Standards Track
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 5012
Title: Requirements for Emergency Context Resolution
with Internet Technologies
Author: H. Schulzrinne, R. Marshall, Ed.
Status:
26 matches
Mail list logo
