Hello,
> The IESG has received a request from the Diameter Maintenance and
> Extensions WG (dime) to consider the following document:
> - 'Realm-Based Redirection In Diameter'
>as Proposed Standard
Sorry for bringing this up so late, but as I was writing my own dynamic
discovery draft for RAD
Paul Hoffman wrote:
> On Aug 15, 2013, at 3:11 PM, Yaron Sheffer
> wrote:
>
> > - A parser that looks for duplicates must be able to detect that
> > {{"a":1, "b":2}:4, {"b":2, "a":1}:5} does in fact have a duplicate
> > key, because the two internal maps (used as keys) are identical. So in
> > ge
>>> parsers need to canonicalize maps to any depth in order to
>>> detect duplicates. This is "complex" by any definition of the word.
It isn't complex in terms of computational efficiency ... you can canonicalize
in O(N log N) and do it while reading.
And the consequence of not using structure-e
On Aug 19, 2013, at 11:08, Tony Finch wrote:
> sharing
CBOR and JSON have in common that their data model is based on trees.
A number of other data representation formats generalize this model to
(directed, usually connected) graphs.
E.g., as you say YAML has ways to explicitly reference a par
> I'm somewhat uncomfortable with that sort of bar for IANA registries in
> general, although I have supported it from time to time. (My discomfort
> with this has grown significantly since my time as an AD). I do not
> support that sort of bar for this registry.
>
> I think we understand each o
--On Sunday, August 18, 2013 17:04 -0700 SM
wrote:
>> I'd love to get more developers in general to participate -
>> whether they're open or closed source doesn't matter. But I
>> don't know how to do that, beyond what we do now. The email
>> lists are free and open. The physical meetings
On Mon, Aug 19, 2013 at 6:18 AM, Larry Masinter wrote:
> >>> parsers need to canonicalize maps to any depth in order to
> >>> detect duplicates. This is "complex" by any definition of the word.
>
> It isn't complex in terms of computational efficiency ... you can
> canonicalize in O(N log N) and
On Aug 18, 2013, at 8:04 PM, SM wrote:
> On reading the second paragraph of the above message I see that you and I
> might have a common objective. You mentioned that you don't know how to do
> that beyond what is done now. I suggested a rate for people with an open
> source affiliation. I
On Monday, August 19, 2013 09:35:25 Hadriel Kaplan wrote:
> On Aug 18, 2013, at 8:04 PM, SM wrote:
> > On reading the second paragraph of the above message I see that you and I
> > might have a common objective. You mentioned that you don't know how to
> > do that beyond what is done now. I sugg
On Mon, Aug 19, 2013 at 7:11 PM, Scott Kitterman wrote:
> > But my point was more that "open source" is meaningless, and not what I
> > think we're missing/need. I agree we need more developers (at least in
> RAI
> > it would help), but whether the things they develop are open source or
> not
> >
Hey David,
Having been down this path a number of times, I would like to
suggest that one shouldn't attempt to qualify any algorithm,
technique, method or approach that may be submitted to the
registration process.
By suggesting that the registry somehow contains only " good "
strategies, without
Several open-source compilers exist. It would not be hard to a) make
a library of modules from RFCs (to deal with IMPORTS), b) make a
cgi-bin compiler. It's not what I do on a daily basis, but if you put
together a cgi-bin where all I need to provide is a command to run on
a file and output warni
Academic might work. "Open source" not so much as other mentioned. Does
"Big Corporation" doing Open Source apply?
I was tempted to propose "non-profit", but also there are organizations
with large budgets. And profit driven ones with not much money.
/as
On 8/18/13 6:21 AM, SM w
Subject: [spfbis] Last Call: (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Mon, Aug 19, 2013 at 06:19:16AM -0700 Quoting The IESG
(iesg-secret...@ietf.org)
>
> The IESG has received a request from the SPF Update WG (spfbis) to
> c
>* The charter disallows major protocol changes -- removing the SPF RR type
>is a direct charter violation; since SPF is being used on the Internet. ...
Uh huh.
$ dig besserwisser.org txt
;; QUESTION SECTION:
;besserwisser.org. IN TXT
;; ANSWER SECTION:
besserwisser.org.
Subject: Re: [spfbis] Last Call: (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Mon, Aug 19, 2013 at 04:05:49PM - Quoting John
Levine (jo...@taugh.com):
> >* The charter disallows major protocol changes -- removing the SPF RR ty
On Monday, August 19, 2013 21:05:33 Måns Nilsson wrote:
> Subject: Re: [spfbis] Last Call: (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Mon, Aug 19, 2013 at 04:05:49PM - Quoting John
Levine (jo...@taugh.com):
> > >* The charte
On 8/18/13 4:04 PM, John Levine wrote:
The anti-hijacking feature causes the confirmation email to
only go to the authors listed on the previous version of the document, so
mail was not sent to me and things are working as expected.
This behavior is not documented to the user when they submit th
* The charter disallows major protocol changes -- removing the SPF RR type
is a direct charter violation; since SPF is being used on the Internet. ...
The SPF working group discussed this issue at painful, extensive length.
As you saw when you read the WG archives, there is a significant intero
Note that I am not the shepherd for this draft, but I am the WG
co-chair.
On Mon, Aug 19, 2013 at 05:05:21PM +0200, Måns Nilsson wrote:
> * The charter disallows major protocol changes -- removing the SPF RR type
> is a direct charter violation; since SPF is being used on the Internet.
That argu
Hola Arturo,
At 07:34 19-08-2013, Arturo Servin wrote:
Academic might work. "Open source" not so much as other
mentioned. Does
"Big Corporation" doing Open Source apply?
I was tempted to propose "non-profit", but also there are
organizations
with large budgets. And profit driv
Hi John,
At 06:11 19-08-2013, John C Klensin wrote:
I think this is bogus and takes us down an undesirable path.
Ok.
First, I note that, in some organizations (including some large
ones), someone might be working on an open source project one
month and a proprietary one the next, or maybe bot
>There is nothing syntactially worng with those entries. I congratulate
>people advocating SPF in TXT records while also writing parsers.
None of your TXT records are SPF records because they don't start with
the required version tag. You have two type 99 records that start
with the version tag,
I'm having a hard time with both sides of the argument, especially the
supposed existence of a "interop problem" which seems to only to be
highlighted to "procedurally" stump the SPF type advocates. I don't
believe there was an adequate answer from the advocates of removing the SPF
RR type and the
Speaking in my capacity as responsible AD for this WG and document, and
the one who is going to have to judge the consensus of this Last Call
and report to the IESG.
On 8/19/13 3:08 PM, Andrew Sullivan wrote:
Note that I am not the shepherd for this draft, but I am the WG
co-chair.
On Mon, A
My apologies: A typo rendering a sentence incoherent that I missed
before hitting "Send":
On 8/19/13 3:48 PM, Pete Resnick wrote:
* The empirical data that was gathered and the conclusions from which
that where published as RFC 6686 are IMNSHO flawed and rushed in
that they
set far too optimis
On 8/19/13 3:48 PM, Pete Resnick wrote:
* The empirical data that was gathered and the conclusions from which
that where published as RFC 6686 are IMNSHO flawed and rushed in
that they
set far too optimistic deadlines for adaptation before declaring
failure.
I think you're going to need subst
On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker wrote:
> On 8/19/13 3:48 PM, Pete Resnick wrote:
>
>> * The empirical data that was gathered and the conclusions from which
> that where published as RFC 6686 are IMNSHO flawed and rushed in
> that they
> set far too optimistic deadlines f
On 8/19/2013 2:04 PM, Murray S. Kucherawy wrote:
Moreover:
What is the premise for seven years being "not long enough"? And what
does constitute "long enough"? And upon what is that last answer based?
It would be wonderful if the boundaries for this test were written down
somewhere, so that w
Hi,
I'm having a hard time with both sides of the argument, especially the
supposed existence of an "interop problem" which seems to only highlight
how to "procedurally" stump the SPF type advocates with a "error
correction" standpoint. What is that error by the way?
I don't believe there
I'm not going to copy the spfbis WG list on this, because this is part
of the IETF last call. No hat.
On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote:
> On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker wrote:
> > From earlier exchanges about this concern, the assertion that I r
On 8/19/2013 2:41 PM, Andrew Sullivan wrote:
So I think it _is_ fair to
say that adoption of features in core infrastructure takes a very long
time, and if one wants to add such features one has to be prepared to
wait.
As long as the generic topic is being commented on...
The difference bet
I will let the document shepherd/editor address particular points in
this and other messages, but on one procedural point:
On 8/19/13 4:10 PM, Hector Santos wrote:
I don't believe there was an adequate answer from the advocates of
removing the SPF RR type...
That's an appropriate issue to rai
Hi,
On Aug 19, 2013, at 12:10 PM, Scott Kitterman wrote:
> Operationally, there are far more problems associated with actually trying to
> use Type 99 than there are with SPF records in Type TXT.
Given the abysmal state of implementation of middleboxes _today_, this isn't
surprising. I'm unsu
--On Monday, August 19, 2013 12:49 -0700 SM
wrote:
>...
>> First, I note that, in some organizations (including some
>> large ones), someone might be working on an open source
>> project one month and a proprietary one the next, or maybe
>> both
>> concurrently. Would it be appropriate for suc
On Monday, August 19, 2013 18:08:00 John C Klensin wrote:
> --On Monday, August 19, 2013 12:49 -0700 SM
>
> wrote:
> >...
> >
> >> First, I note that, in some organizations (including some
> >> large ones), someone might be working on an open source
> >> project one month and a proprietary one th
On Monday, August 19, 2013 14:54:44 David Conrad wrote:
> Hi,
>
> On Aug 19, 2013, at 12:10 PM, Scott Kitterman wrote:
> > Operationally, there are far more problems associated with actually trying
> > to use Type 99 than there are with SPF records in Type TXT.
>
> Given the abysmal state of imp
>AFAICT, no one is arguing that overloading TXT in the
>way recommended by this draft is a good idea, rather the best arguments appear
>to be that it is a pragmatic
>"least bad" solution to the fact that (a) people often implement (poorly) the
>very least they can get away
>with and (b) it can ta
Hi Hector,
At 14:10 19-08-2013, Hector Santos wrote:
I'm having a hard time with both sides of the argument, especially
the supposed existence of an "interop problem" which seems to only
highlight how to "procedurally" stump the SPF type advocates with a
"error correction" standpoint. What is
On Aug 19, 2013, at 5:10 PM, Hector Santos wrote:
> This will allow coders to add the optimized logic for usage. It will also
> allow for new problem solving seeds to be laid down. It will hopefully get
> the DNS software vendors to finally add direct support for unnamed TYPE
> support (query
In message <20130819214139.gb19...@mx1.yitter.info>, Andrew Sullivan writes:
> I'm not going to copy the spfbis WG list on this, because this is part
> of the IETF last call. No hat.
>
> On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote:
> > On Mon, Aug 19, 2013 at 1:59 PM, Dav
Again, I'm not the shepherd on this, but I was involved in the
consensus call in the WG when we determined that the WG wanted to
deprecate use of RRTYPE 99. (Note that this "deprecation" means just
that users of SPF stop publishing that record. There's nothing in the
draft to remove the RRTYPE, a
Subject: Re: [spfbis] Last Call: (Sender
Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to
Proposed Standard Date: Mon, Aug 19, 2013 at 03:59:50PM -0400 Quoting John R
Levine (jo...@taugh.com
> >>>* The charter disallows major protocol changes -- removing the SPF RR
Subject: Re: SPF TYPE support Date: Mon, Aug 19, 2013 at 04:42:42PM -0700
Quoting S Moonesamy (sm+i...@elandsys.com):
> I personally do not think that it is appropriate to ask any working
> group participant to "shut up". I welcome hearing arguments and I
> expect a working group to carefully c
In message <20130820022209.ga56...@mx1.yitter.info>, Andrew Sullivan writes:
> Again, I'm not the shepherd on this, but I was involved in the
> consensus call in the WG when we determined that the WG wanted to
> deprecate use of RRTYPE 99. (Note that this "deprecation" means just
> that users of
John,
On Aug 19, 2013, at 3:58 PM, John Levine wrote:
>> AFAICT, no one is arguing that overloading TXT in the
>> way recommended by this draft is a good idea, rather the best arguments
>> appear to be that it is a pragmatic
>> "least bad" solution to the fact that (a) people often implement (po
On Monday, August 19, 2013 21:57:26 David Conrad wrote:
> John,
>
> On Aug 19, 2013, at 3:58 PM, John Levine wrote:
> >> AFAICT, no one is arguing that overloading TXT in the
> >> way recommended by this draft is a good idea, rather the best arguments
> >> appear to be that it is a pragmatic "lea
At 08:05 19-08-2013, MÃns Nilsson wrote:
I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as
RFC unless substantial parts are reworked.
* The charter disallows major protocol changes -- removing the SPF RR type
is a direct charter violation; since SPF is being used on the Inter
so, according to your message, one lesson i might take from this is, if
i want to deploy a new hack which needs an rrtype, not to use txt in the
interim. i will be caught in a mess which will appear to be of my own
making. is that somewhat correct?
randy
On 8/19/2013 8:01 PM, Måns Nilsson wrote:
The repeated assertions of "This has been discussed already" are in effect
"shut up", but slightly more polite. I complied until last call. As was
recommended by wg chairs.
There is a fundamental difference between telling someone to shut up and
askin
On 8/19/2013 10:14 PM, Randy Bush wrote:
so, according to your message, one lesson i might take from this is, if
i want to deploy a new hack which needs an rrtype, not to use txt in the
interim. i will be caught in a mess which will appear to be of my own
making. is that somewhat correct?
Wh
On Aug 19, 2013, at 10:14 PM, Randy Bush wrote:
> so, according to your message, one lesson i might take from this is, if
> i want to deploy a new hack which needs an rrtype, not to use txt in the
> interim. i will be caught in a mess which will appear to be of my own
> making. is that somewhat
On 20 aug 2013, at 07:21, Dave Crocker wrote:
> The first is that there now a number of other apps using TXT records,
> with no problems, because they are stored under scoping nodes
> (underscore-prefaced names). This approach might be aesthetically
> displeasing, but it works just fine.
Hi,
> When relying on S-NAPTR (RFC3958), redirection is only possible inside
> sub-domains of the original domain name.
I don't think that's true. RFC3958 has exactly this use case in it's
first example section (2.2): a domain example.com redirects service
"EM:protA" to another domain, namely so
54 matches
Mail list logo
