Tony Finch wrote:
> On Thu, 27 Mar 2008, Matti Aarnio wrote:
>> There will be lots of legacy codes using legacy APIs for long future.
>> I do use getaddrinfo() API myself, and permit it do all queries to
>> get addresses. Thus it will also query for A in addition to .
>> It can even be order
David Morris wrote:
>
> On Fri, 28 Mar 2008, Keith Moore wrote:
>
>>> If there were some serious technical consequence for lack of the MX record
>>> I would be
>>> all for specifying its use. Operational practice with A records shows that
>>> there is no real issue,
>> only if you ignore the p
On Fri, 28 Mar 2008, Keith Moore wrote:
> > If there were some serious technical consequence for lack of the MX record
> > I would be
> > all for specifying its use. Operational practice with A records shows that
> > there is no real issue,
>
> only if you ignore the problems that have been obs
> That is all well and good, but it is completely of value to the receiving
> MTA, and under their complete control. There is nothing that requires a
> receiving MTA to follow this model, despite what others may see as value.
well, if you want to receive mail from other domains without special
ar
Total of 257 messages in the last 7 days.
script run at: Fri Mar 28 00:53:01 EDT 2008
Messages | Bytes| Who
+--++--+
6.23% | 16 | 5.84% | 102664 | [EMAIL PROTECTED]
4.28% | 11 | 7.20% | 126614 | [EMAIL PROTECTE
--On Friday, 28 March, 2008 11:38 +1100 Mark Andrews
<[EMAIL PROTECTED]> wrote:
>> OTOH, I think standardizing this convention makes all sorts
>> of sense, but not, of course, in 2821bis.
>
> Why not in 2821bis? Is 2821bis really that time critical?
It is on its way to Draft Standard.
>
> On 27 Mar 2008, at 20:38 , Mark Andrews wrote:
>
> >> OTOH, I think standardizing this convention makes all sorts of
> >> sense, but
> >> not, of course, in 2821bis.
> >
> > Why not in 2821bis? Is 2821bis really that time critical?
>
> I would prefer to see the "empty field" intentio
On 27 Mar 2008, at 20:38 , Mark Andrews wrote:
>> OTOH, I think standardizing this convention makes all sorts of
>> sense, but
>> not, of course, in 2821bis.
>
> Why not in 2821bis? Is 2821bis really that time critical?
I would prefer to see the "empty field" intention implicit in "MX 0
> > > In an IETF that believes the potential recursion of URNs and
> > > NAPTR records is reasonable, it is really hard for me to get
> > > excited about that one possible extra lookup. YMMD, of course.
>
> I can't get excited about this either.
>
> > Doug's issue, which sparked off this l
> > In an IETF that believes the potential recursion of URNs and
> > NAPTR records is reasonable, it is really hard for me to get
> > excited about that one possible extra lookup. YMMD, of course.
I can't get excited about this either.
> Doug's issue, which sparked off this latest debate,
On Thu, 27 Mar 2008, Matti Aarnio wrote:
>
> There will be lots of legacy codes using legacy APIs for long future.
> I do use getaddrinfo() API myself, and permit it do all queries to
> get addresses. Thus it will also query for A in addition to .
> It can even be ordered to ignore IPv4 or I
>
>
> --On Wednesday, 26 March, 2008 14:26 -0700 "Hallam-Baker,
> Phillip" <[EMAIL PROTECTED]> wrote:
>
> >
> > I don't undestand the reasoning here.
> >
> > My understanding is that we implicitly deprecated receivers
> > relying on fallback to A in 2821.
>
> We did no such thing.
>
> >
--On Wednesday, 26 March, 2008 14:26 -0700 "Hallam-Baker,
Phillip" <[EMAIL PROTECTED]> wrote:
>
> I don't undestand the reasoning here.
>
> My understanding is that we implicitly deprecated receivers
> relying on fallback to A in 2821.
We did no such thing.
> Section 5 makes it clear
> th
On Wed, Mar 26, 2008 at 10:46:37AM -0400, Tony Hansen wrote:
> ><[EMAIL PROTECTED]> wrote:
> >
> >>...
> >>>It would be needed until IPv6 takes over.
> >>It will be needed even *after* IPv6 takes over. There will
> >>be lots of queries for A records long after the majority
> >>of hosts
--On Thursday, 27 March, 2008 09:00 +0200 Matti Aarnio
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 26, 2008 at 10:46:37AM -0400, Tony Hansen wrote:
>> > <[EMAIL PROTECTED]> wrote:
>> >
>> >> ...
>> >>> It would be needed until IPv6 takes over.
>> >> It will be needed even *after* IPv6 takes o
While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents. We can have a meta-discussion about
where the clarifications belong, but it seems to me
that the WG consensus definitely assumed that scope
and no wider scope. I'd be happy
--On Thursday, 27 March, 2008 12:31 -0700 "Hallam-Baker,
Phillip" <[EMAIL PROTECTED]> wrote:
> The key issue here is whether people who rely on are
> likely to achieve their desired result. Today it does not
> matter because anyone who relies on alone with no A
> fallback is going to r
The key issue here is whether people who rely on are likely to
achieve their desired result. Today it does not matter because anyone
who relies on alone with no A fallback is going to receive almost
no mail.
That in turn is going to depend on whether software implementations are
written
*>
*> Good point Jari,
*>
*> Can I also remind you to check in the RFC Errata pages to make sure you
pick
*> up any errors that have been flagged since RFC publication.
*>
*> Adrian
Enter the RFC number to the RFC Editor search engine at
http://www.rfc-editor.org/rfcsearch.html
--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman <[EMAIL PROTECTED]>
wrote:
> I would think that the document would gain in clarity if it explicitly
> ties the incoming rights to the streams as defined in RFC4844 and also
> explicitly calls out that if new streams would be defined those should
Keith Moore wrote:
> Tony Hain wrote:
> > Your arguments make no sense. Any service that has an MX creates
> > absolutely no cost, and the fallback to only makes one last
> > attempt to deliver the mail before giving up. Trying to force the
> > recipient MTA to publish an MX to avoid delivery
You are completely incorrect in describing MX records as no more than an
optimization. The MX record defines the mail SERVICE. An A or record
defines a HOST.
Nor am I rewriting history here, the early RFCs that describe the emergence of
the mail service and the DNS make it very clear that
On Wed, 26 Mar 2008, IAB Chair wrote:
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-iab-protocol-success-03.txt
The document seems to be in good shape and is useful.
Two comments:
Case study A4 discusses inter-domain multicast vs application
overlays. It seems as
Stewart, Adrian,
> Of course you mean the *relevant* errata
Right. Generally speaking, I would go over the reported erratas and see
which ones of them need to be adopted. Some might even need WG discussion.
Jari
___
IETF mailing list
IETF@ietf.org
h
Adrian Farrel wrote:
> Good point Jari,
>
> Can I also remind you to check in the RFC Errata pages to make sure you pick
> up any errors that have been flagged since RFC publication.
>
>
>
Of course you mean the *relevant* errata - the RFC Erratas page is so
full of junk these days that it is
Good point Jari,
Can I also remind you to check in the RFC Errata pages to make sure you pick
up any errors that have been flagged since RFC publication.
Adrian
- Original Message -
From: "Jari Arkko" <[EMAIL PROTECTED]>
To: "IETF Discussion" ; "Working Group Chairs"
<[EMAIL PROTECTED]
I have seen a number of problems recently with bis documents
accidentally ignoring changes introduced by the RFC Editor to the
original RFC. In some cases this has gone unnoticed all the way until
IETF Last Call.
The problem is that authors start with THEIR version of the source code
for the docum
While reviewing the documents I tried to determine how the 4 streams
currently defined in RFC4844 fit into the framework.
Although the stream is not specifically mentioned it is clear that the
incoming rights document applies to the IETF Stream.
To me it is clear that a contribution to t
Due to our business characteristics, we usually transfer large volumes of
data such as engineering or architectural drawings across long distances. We
needed a WAN optimization solution that would provide our remote employees
the same application access environment as in our headquarters, together
29 matches
Mail list logo
