I've added extra explanatory text in section 2 as well as the Security
Considerations section. It's normative, but dependent on the use case
being appropriate, which gives emphasis to the implementor but still
allows the right thing to be done.
Lisa
On Fri, Nov 13, 2009 at 4:16 PM, Brian E Carpe
On Tue, Nov 17, 2009 at 12:15 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> In fact, lightning talks are SOP at most operator group meetings.
> I think that would be an excellent experiment.
>
>Brian
>
> I agree, and in fact I've suggested lightning talks too; I think it tilts
Hi,
On Thu, Oct 29, 2009 at 11:29 AM, SM wrote:
>
> In Section 2:
>
> "If the entire patch document cannot be successfully applied
> then the server MUST fail the entire request, applying none
> of the changes."
>
> I suggest rewriting the sentence:
>
> If the entire patch document cannot
Hi,
On Wed, Oct 28, 2009 at 11:03 AM, Nikunj R. Mehta
wrote:
>
> This draft places unreasonable restriction on servers about processing
> requests. Specifically, in §2.2,
>
> [[
> Concurrent modification: When a server receives multiple concurrent requests
> to modify a resource, those requests S
On Thu, Oct 1, 2009 at 3:42 AM, Simon Josefsson wrote:
> I object to publishing these IDNA documents as a Draft Standard. I
> don't view IDNA2008 as a revision of the earlier IDNA2003 protocol. The
> design goals have changed since the first IDNA version. Finally, there
> have been little imple
You can probably blame my vacation as well as process defaults for some
confusion... I was already in Canada last week when we had the telechat
where the IESG approved sending out the 1-line diff proposed for the
charter, and I didn't take the time or stretch the process so that the
charter discuss
I think this is also a good idea and will try to come up with
something for the next draft.
thanks,
Lisa
On Wed, May 27, 2009 at 2:15 PM, Thomas Narten wrote:
> Overall, I like this document and support it going forward.
>
> One thing it doesn't mention (and did come up when I was an AD) is the
Will do, assuming my co-author agrees.
On Tue, May 26, 2009 at 3:58 PM, Paul Hoffman wrote:
> At 2:45 PM -0700 5/26/09, Lisa Dusseault wrote:
>>Good suggestions. I do agree with explaining why a subset was tested
>>and how that subset was chosen. In some cases, however, list
support) or even contrary to privacy agreements.
Lisa
On Tue, May 26, 2009 at 12:38 PM, Stephane Bortzmeyer wrote:
> On Tue, May 26, 2009 at 09:50:52AM -0700,
> Lisa Dusseault wrote
> a message of 43 lines which said:
>
>> Do you have any suggestions for criteria tha
That's an excellent question, but I think like so many others it has
to fall under the judgement of the person writing the implementation
report. Is it OK to just test 2 implementations or is it important to
test 2 servers and 2 clients? It might be possible to go to an
interoperability forum and
I'm the sponsor of the DNSBL Internet-Draft. I've been following this
discussion and it seems to me there have been fair objections raised
to putting the document as-is on the Standards Track. I'll consult with
the authors about whether they'd like to figure out exactly what the IETF
does have co
On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani <[EMAIL PROTECTED]>wrote:
> Narayanan, Vidya wrote:
>
> Peer selection is important to ISPs from a network utilization perspective
>> and to peers themselves from a performance perspective. That automatically
>> makes peer selection a function of m
Lakshminath and Vidya,
Vijay, Enrico and Stefano have said what I was going to say (e.g. below) --
as sponsoring AD for this charter I've been following the WG discussion,
working with the rest of the IESG, and talking to people to confirm that
there's better consensus on the list, even if there w
On Sep 8, 2008, at 5:06 AM, John C Klensin wrote:
>
> Please reserve Last Calls for situations in which community
> input or demonstrations of community consensus are actually
> needed.
Perhaps an announcement specifically calling out the approval of the
errata would have been better. I was t
kscatter, itself a form of spam.
Lisa
-Matthew
On 8/7/08 6:44 PM, Lisa Dusseault wrote:
Hi,
I'm on vacation next week so I haven't put this document on the Aug
14 IESG telechat. The Aug 28 telechat is the next opportunity for
IESG Evaluation. That timing gives you three week
Hi,
I'm on vacation next week so I haven't put this document on the Aug 14
IESG telechat. The Aug 28 telechat is the next opportunity for IESG
Evaluation. That timing gives you three weeks before the first
possible decision on the document.
The WG considered your arguments in the past y
On Aug 7, 2008, at 10:47 AM, Tim Bray wrote:
On Thu, Aug 7, 2008 at 10:23 AM, Keith Moore <[EMAIL PROTECTED]
> wrote:
The TAG is in fact clearly correct when they state that introduction
of new URI schemes is quite expensive.
To me it seems that this depends on the extent to which those ne
On Aug 7, 2008, at 3:48 AM, Julian Reschke wrote:
Hannes,
thanks for the pointers
Tschofenig, Hannes (NSN - FI/Espoo) wrote:
...
Reading through the mails again I unfortunately cannot find a
strong recommendations. It seems that reading through RFC 3205 we
got confused.
Initially, th
On Aug 6, 2008, at 11:59 AM, Julian Reschke wrote:
Is the concern that a client that does a GET on an HTTP URI, and
receive a response with that MIME type, still wouldn't know whether
it's seeing a genuine HELD response, or just some static XML
document served by a web server?
Before t
I believe I instigated the creation of a new URI scheme for HELD.
That's not to say, however, that I or the IESG required that solution
-- to elaborate on what Martin said, I raised some issues, and the URI
scheme was added after my review, but other solutions might work
instead of new URI
I had some email outage and only saw this after today's IESG
Evaluation, sorry.
I didn't see consensus for a particular change as a result of this
conversation. There was widespread agreement that X-headers are
messy, but not what to say about them.
Lisa
On May 21, 2008, at 7:22 PM, Brian
I can assure you, I at least was anticipating that the IESG (and other
people handling errata) would be doing *more* work in classifying
errata if we have the three categories. The goal as I see it is to
avoid presenting 50 errata on an RFC to a user, without any sorting or
focus, when onl
Hi Keith,
I've been working with Tony and John very closely on this issue, and
whether it smells foul or not, I think this is the best we can do.
Tony was very diligent about having conversation on all aspects and
looking at a number of different resolutions including the one he
recommend
On Mar 8, 2008, at 10:39 PM, Frank Ellermann wrote:
That is also a part of the ION concept: *Public*, *documented*,
and *binding* rules without the need to track down obscure IAB
pages, IESG minutes, or recent change patrol in a wgchairs wiki.
I agree with the desire, and we have discussed
ur comments to the IESG mailing list ([EMAIL PROTECTED]) by
> March 4,
> 2008.
>
> Internationalized Domain Name (idn)
> =
> Last modified: 2008-02-18
>
> Current Status: Proposed Working Group
>
> Chair(s):
>
> TBD
>
> Applications
On Mar 3, 2008, at 5:38 AM, Stephane Bortzmeyer wrote:
- Separate requirements for valid IDNs at registration time, vs. at
resolution time
This means casting in stone one specific approach, and a dangerous
one.. And the discussions on the existing
idna-update list show that the decision o
On Nov 23, 2007, at 12:29 PM, Andrew Newton wrote:
On Nov 21, 2007, at 6:01 PM, Cullen Jennings wrote:
1) as far as I understand the needs to defining an address for
sending SMS, I would want to understand why it would not be better
to a tel URI than define a new type. Defining new types
ion might occur.
You might call for participation, because without people like you
contributing text and volunteering to edit and review, it can't get
done :)
Thanks,
Lisa
On Sep 20, 2007, at 9:33 AM, Tom.Petch wrote:
- Original Message -
From: "Lisa Dusseault" <
I would be happy to encourage work on IETF-wide guidance for XML
usage (I guess that's what I'm doing now?). The Apps area has an XML
directorate and supposedly we have some XML expertise to call on --
sometimes we do XML usage reviews for the other IETF areas.
Lisa
On Sep 18, 2007, at 10
On Aug 25, 2007, at 7:11 PM, Ben Finney wrote:
I'd like to discuss this with the people who made the original RFC
1345 character mnemonic table. How would I get in touch with the
authors of RFC 1345?
It wasn't my intention to write a new discussion draft, but it seems
that since my purpose is
y specific text this could help the authors.
Thanks,
Lisa
On May 22, 2007, at 4:29 PM, Lisa Dusseault wrote:
Thanks for everybody's input on this. I interpret the discussion
as showing consensus for a comment with a warning near the
definition of LWSP.
Details: I counted 18 opinions.
org/pipermail/ietf-dkim/2007q1/007295.html
- https://datatracker.ietf.org/public/pidtracker.cgi?
command=view_comment&id=66440 (in this tracker comment, Chris
Newman recommended to remove LWSP, but for backward-compatibility
it's probably better to keep it and re
On May 14, 2007, at 3:55 PM, Dave Crocker wrote:
Lisa Dusseault wrote:
The IESG reviewed <http://www.ietf.org/internet-drafts/draft-
crocker-rfc4234bis-00.txt> for publication as Internet Standard
and would like to know if there is consensus to recommend against
the use of LWSP in
https://datatracker.ietf.org/public/pidtracker.cgi?
command=view_comment&id=66440 (in this tracker comment, Chris Newman
recommended to remove LWSP, but for backward-compatibility it's
probably better to keep it and recommend against use)
Thanks for your input,
Hi Philip, thanks for the review. But are we looking at the same
version of this doc? We dealt with this after doing a pseudo-WG-last-
call on the SMTP mailing list and the -07 draft now has:
To ensure interoperability, client and server implementations
of this extension
On Jan 1, 2007, at 4:49 PM, John C Klensin wrote:
... regardless of what we do, some
of these will ultimately hit the IESG during final review (as
well as agreeing that the Kerberos WG is a poor example).
However, I think your comment could be construed as a little too
accepting of the situation
On Dec 31, 2006, at 2:27 PM, Lakshminath Dondeti wrote:
There is perhaps one more aspect to "Can somebody explain ..." that
is worth considering. In some cases, the AD simply does not have
the expertise or simply has incorrect/wrong understanding. In that
case, the burden is on the autho
On Dec 29, 2006, at 8:44 AM, Dave Crocker wrote:
Meta-point:
Something quite basic that is missing from the draft on
Discuss Criteria is a requirement that any Discuss not only
explain its precise normative basis, but that it give a clear
statement of what actions must be
On Sep 23, 2006, at 2:20 AM, Julian Reschke wrote:
But as a matter of fact, draft-newman-i18n-comparator-14 doesn't
define any collations that would actually solve the Unicode NF
issue, so it's not really clear how this helps CalDAV (except that
it now uses a framework in which the solut
Hi Julian!I apologize for not responding to your comments made during the 2nd last call (the last call specifically on the topic of the downref), but I can assure you we (Cyrus, Bernard and I) didn't ignore those comments, nor would we ever do that intentionally. You've made many useful comments t
org/internet-drafts/draft-whitehead-http-etag-00.txt> with
no consensus on the basic model or apparent drive to come to
consensus. Got any feedback on that draft?
Lisa
-wsv
On Jun 20, 2006, at 8:13 AM, Lisa Dusseault wrote:
Wilfredo, does it make a difference that CalDA
On Jun 20, 2006, at 9:56 AM, Julian Reschke wrote:
Lisa Dusseault schrieb:
Xythos WFC and Chandler (the Zanshin library that does WebDAV in
python) behave this way and make the assumption I describe. How
else would you expect a caching or synching client to behave after
doing a PUT
assumptions that are only valid on some server implementations.
We know we need a solution; I just don't agree that CalDAV is the
right place to specify it. I do understand how it's convenient.
-wsv
On Jun 19, 2006, at 12:32 PM, Lisa Dusseault wrote:
It's worse
ETag?
Even if there are such clients, the behavior we describe avoids nasty
errors on both such clients and clients like WFC. It's the
conservative choice.
Lisa
On Jun 19, 2006, at 12:41 PM, Julian Reschke wrote:
Lisa Dusseault schrieb:
On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez
On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote:
I agree with Julian.
As we've mentioned before, Apache returns a weak ETag on PUT,
which turns into a strong ETag sometime later. If clients rely on
being able to use that ETag on a GET later, they won't work with
Apache, and
Thanks for the input. Speaking as a document author here, I'm
confident we've made a decent set of tradeoffs, balancing possible
risks against benefits, and attempting to minimize the risks too.
The basic risk is that any requirements related to ETags may conflict
with future requirements.
tion.
I approve of this escalation and think we should not set the bar so
high that no WG or DL can ever successfully send the message that a
PR-action sends.
Lisa Dusseault
On Jan 20, 2006, at 6:57 AM, Michael Everson wrote:
From: Sam Hartman [mailto:[EMAIL PROTECTED]
This is why
On Aug 10, 2005, at 1:40 AM, Iljitsch van Beijnum wrote:
I've been thinking about this on and off for a day, and I'm not
convinced that having running code at the time a specification is
first fleshed out would be all that helpful.
Can you point to any instance in recent IETF history (after
I've previously announced the availability of this server to WG Chairs,
now to announce it more widely:
http://ietf.webdav.org
There are already a few WG directories on this server such as
http://ietf.webdav.org/webdav
http://ietf.webdav.org/enum
If you have presentation material or meeting notes
There used to exist a DASL WG and its main proposal included a framework
for sending Search requests to Web servers (including WebDAV servers).
The framework was complemented by one proposed syntax for searching
the resources stored directly on that server according to their
metadata values. Anoth
I'm also concerned that conferencing semantics could lead to
basic interoperability problems that would be difficult to
surmount. If you can imagine XMPP in common usage for either
instant messaging or software agent communication (think 'bots')
and also SIMPLE in common usage for instant messag
51 matches
Mail list logo
