Subject: New AtomPubIssuesList for 2004/07/07

From: Sam Ruby <[email-masked]>
Date: Wed, 07 Jul 2004 20:45:09 -0400

Sam Ruby wrote:

http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

I'm suggesting two security related items to proceed: 
PaceSecurityServices, PaceFeedSignature (one affecting the protocol, one 
the format).

PaceConsistentMimeType, PaceElementOrder, and PaceSyntaxGuidelines are 
minor/editorial.

PaceInterop, PaceContentTypeHandling, PaceXmlValidity,
ErrorReportingMechanism all have been withdrawn by their respective 
authors without an objection noted on the mailing list.  Unless somebody 
objects, these will proceed to closure.

- Sam Ruby

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 7 Jul 2004 21:08:06 -0400

-1 

For the following reasons:

1. The Pace is rather vauge. 
    Is there a definitive list of security services could be placed in
such an element?
    If there are more than one such security service how is priority set?
    Does 'security' applied to an atom:feed imply the same security
for all the entries?
2. Encryption and possibly signatures require XML to be canonicalized,
    which is not only a burden but is not mentioned anywhere in the Pace.
3. Because of the complexity of producing and consuming such a feed
    I do not believe this functionality belongs in the core of Atom.

   Thanks,
   -joe

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 7 Jul 2004 21:26:00 -0400

There is too much in this one Pace to just +1 or -1
the whole thing.

In the section on the AtomAPI:
---------------------------------------------

+1 on Digest and TLS

I support referencing and strongly encouraging
the use of standard authentication and 
encryption mechanisms.

-1 to WSSE

On the other hand I do not like the WSSE
mechanism ( wide open to man in the middle
attacks and requires both the client and the
server to store plaintext passwords ). 
If we must create a new authentication mechanism 
I would prefer to use an updated version of [1] that supports
multiple kinds of hashes and mandates 'auth-int'. 
This will provide better security to implementors, 
easier implementations for systems that already store
hashed values of passwords, and provides protection
against man in the middle attacks.

If we must create a new authentication mechanism
than I would also like it to be a seperate RFC from the
the AtomAPI, just as HTTP is broken into 
RFC 2616 and 2617.

[1] http://bitworking.org/news/New_AtomAPI_Implementation_Release2

---

From: Walter Underwood <[email-masked]>
Date: Wed, 07 Jul 2004 20:18:10 -0700

--On Wednesday, July 7, 2004 8:45 PM -0400 Sam Ruby <[email-masked]> wrote:
> ErrorReportingMechanism all have been withdrawn by their respective authors without an objection noted on the mailing list.  Unless somebody objects, these will proceed to closure.

I think that PaceInterop is very useful and should continue.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 08 Jul 2004 04:51:45 +0100

> objects, these will proceed to closure.

Please consider adding PacePutIpAddrInEntry to that list.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Thu, 08 Jul 2004 00:13:05 -0400

Bill de hÓra wrote:

>> authors without an objection noted on the mailing list.  Unless 
>> somebody objects, these will proceed to closure.
> 

My mistake:

http://www.imc.org/atom-syntax/mail-archive/msg06028.html

I've added it to the list.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 08 Jul 2004 11:09:06 -0400

>In the section on the AtomAPI:
+1

>-1 to WSSE
...

>the AtomAPI, just as HTTP is broken into 
I'm fine with accepting the Pace as is. If we want to make AuthForBob a 
seperate document, we can do that at any time. Saying it should go in a 
document that's not (yet) a deliverable resembles handwaving a little 
too closely for me. I'm not a big fan of WSSE, but it will be easy to 
replace that section with something else. Let's just get it in there for 
now.

There's also the section "Security Considerations"*//*/**/, which I 
generally agree with. I would rewrite it a bit to highlight the fact 
that all authentication is based on RFC 2617, it's just that we've added 
an extension authentication scheme (the RFC allows this).

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 8 Jul 2004 13:10:15 -0400

> replace that section with something else. Let's just get it in there for

Agreed.

    Thanks,
    -joe

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 8 Jul 2004 13:29:03 -0400

> > replace that section with something else. Let's just get it in there for

Ok, let me clarify that a little, *if* we agree to keep WSSE
then I am not opposed to starting documenting it in the current I-D and 
then moving it off into it's own document later.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jul 2004 18:21:45 -0700

OK, I'm seeing a trend here and want to check. It sounds like people 
agree that we want Digest Auth as a SHOULD (not a MUST), not to give 
a SHOULD for the WSSE-like mechanism, and not to describe it in the 
core protocol document. Does that sound right?

If so, I'll update the Pace and add text that implementers should 
also assume that there will be other authentication mechanisms 
needed, some text about why Digest Auth isn't universal, and 
suggestions for folks who will create new auth mechanisms.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 12 Jul 2004 21:40:35 -0400

+1

    -joe

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 19:01:35 -0700

On Jul 12, 2004, at 6:21 PM, Paul Hoffman / IMC wrote:

> agree that we want Digest Auth as a SHOULD (not a MUST), not to give a 
> SHOULD for the WSSE-like mechanism, and not to describe it in the core 
> protocol document. Does that sound right?

I'm a little surprised not to see more people standing up for WSSE, but 
I don't see them.  So +1 I guess. -Tim

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jul 2004 19:12:04 -0700

At 7:01 PM -0700 7/12/04, Tim Bray wrote:
>I'm a little surprised not to see more people standing up for WSSE, 
>but I don't see them.  So +1 I guess. -Tim

If someone wants WSSE-like, they can easily write a short Internet 
Draft on it. If they do so before we're done with the protocol 
document, we might even refer to it as a MAY, and as a suggestion for 
a good way of doing auth for Atom.

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Mon, 12 Jul 2004 22:18:05 -0400

> core protocol document. Does that sound right?

-1. You are correct that no one is enthusiastic about WSSE. However, many
have spoken in favor of a Digest workalike with different header names, so
Apache doesn't eat them. I think the spec should reference or define one
such mechanism.

Robert Sayre

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jul 2004 19:54:31 -0700

>Apache doesn't eat them. I think the spec should reference or define one

I heard folks now wanting the spec to define new ones. Assuming 
someone else creates such a mechanism, I'm fine with the base spec 
referencing it as a MAY. Is that what you were thinking, or did you 
want a SHOULD that is parallel to Digest Auth?

--Paul Hoffman, Director

---

From: [email-masked] (John Panzer)
Date: Mon, 12 Jul 2004 22:58:44 -0700

> protocol document. Does that sound right?

PaceSecurityServices says currently that one of {HTTP Digest, WSSE-style 
authentication} MUST be supported.

I'm neutral on WSSE, so +1 to removing WSSE on grounds of reduced 
complexity.

I am uncertain about making Digest Auth a SHOULD rather than a MUST.  
What's the reason for leaving the wriggle room?

-John Panzer

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 13 Jul 2004 08:30:26 -0400

> What's the reason for leaving the wriggle room?

Some implementations (most wikis, some comment systems) have no need
for authentication of any kind.

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Tue, 13 Jul 2004 09:43:28 -0400

Paul Hoffman / IMC wrote:

> Assuming someone else creates such a mechanism, I'm fine with the base 
> spec referencing it as a MAY. Is that what you were thinking, or did 
> you want a SHOULD that is parallel to Digest Auth?

I think the spec isn't done until we have an optional authentication 
scheme that works for CGI scripts on standard Apache configurations. We 
*know* that the existing options are inadequate for this common use 
case. I'm fine with the base spec referencing another draft as a MAY.

Robert Sayre

---

From: Elias Torres <[email-masked]>
Date: Tue, 13 Jul 2004 09:58:20 -0400

+1 on Digest-only and +1 on removing WSSE.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 13 Jul 2004 07:47:17 -0700

At 9:43 AM -0400 7/13/04, Robert Sayre wrote:
>scheme that works for CGI scripts on standard Apache configurations.

OK

>  We *know* that the existing options are inadequate for this common use case.

Fully agree. That's why I said we should have wording in the spec 
talking about it. I was surprised when I found out about the 
limitation, and I suspect many folks in the IETF who will be 
reviewing the document will be as well.

>  I'm fine with the base spec referencing another draft as a MAY.

Good. If someone comes forwards with another auth mechanism that the 
WG agrees is appropriate, it is a good idea for this section of the 
document to say "For example, see the Foo document; this MAY be used 
for authentiation."

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 13 Jul 2004 07:43:21 -0700

>for authentication of any kind.

Exactly right. For interoperability, no authentication is needed, 
since some systems will not want it. If you are going to use 
authentication, you SHOULD use Digest Auth. If you can't use Digest 
Auth but you still need authentication, you need to use something 
outside the spec.

--Paul Hoffman, Director

---

From: Sam Ruby <[email-masked]>
Date: Tue, 13 Jul 2004 11:28:57 -0400

> case. I'm fine with the base spec referencing another draft as a MAY.

I think you guys are agreeing, but not directly addressing one key 
point: we need a proposal around which there is rough consensus and 
running code.  If we get to 1.0 and such a proposal is not written, then 
we should view this as an indication that it is not a "must have" feature.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Tue, 13 Jul 2004 11:45:27 -0400

Sam Ruby wrote:

> running code.  If we get to 1.0 and such a proposal is not written, 
> then we should view this as an indication that it is not a "must have" 
> feature.

Absolutely. I just want to make sure the chairs recognize that voices in 
favor of a Digest-like scheme are not necessarily advocating the scheme 
defined in RFC 2617.

Robert Sayre

---

From: [email-masked] (John Panzer)
Date: Tue, 13 Jul 2004 08:56:19 -0700

> Auth but you still need authentication, you need to use something 

+1 to SHOULD for both.

I'm still a little nervous about applying this logic to clients (what 
reason does a client have for not implementing at least Digest Auth?) 
but it's a nitpick. 

-John

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 09:49:50 -0400

As we are on the cusp of releasing a -01 set of drafs, I thought I would 
keep this iteration light... PaceEntryIdRequired and PaceLang look like 
they should be easy to dispose of.

For the moment, I'm keeping PaceSecurityServices listed as under active 
discission as the last status I saw was Tim asking a question to the 
editors, and Robert replying concerning a portion which he did not 
perceive as quite having reached consensus.

Finally, PacePutDelete was withdrawn by its author.

- Sam Ruby

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 14 Jul 2004 10:10:48 -0400

> http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

PaceShouldBeWellFormed has been withdrawn.  PaceMustBeWellFormed
received no dissent (just one clarification).  I recommend we include
it in -01.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 07:32:40 -0700

> received no dissent (just one clarification).  I recommend we include

Sorry.  I strongly dissent on PaceMustBeWellFormed, and also on the 
withdrawing of PaceShouldBeWellFormed.  I think we haven't really faced 
up to these as a community and they TOTALLY need more discussion.  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Wed, 14 Jul 2004 10:42:53 -0400

> received no dissent (just one clarification).  I recommend we include

Thanks.  I've added PaceShouldBeWellFormed.  I have some comments about 
PaceMustBeWellFormed that I will make in a separate email.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Wed, 14 Jul 2004 13:21:09 -0400

Sam Ruby wrote:

> For the moment, I'm keeping PaceSecurityServices listed as under 
> active discission as the last status I saw was Tim asking a question 
> to the editors, and Robert replying concerning a portion which he did 
> not perceive as quite having reached consensus.

The chairs have decided to move forward with PaceSecurityServices for 
the protocol, but not the format. I've removed the XMLDSig content from 
the Pace, and created PaceDigitalSignatures[1] to discuss DSig.

For the protocol, the chairs have decided on the following approach for 
this draft:

* Eliminate references to WSSE, and substitute with TBD references to an 
external authentication mechanism
* include the first paragraph of "K,kk.1 WSSE-style Authentication", 
because that's a good explanation of the situation
* Use all of the text about Digest roughly as-is.

I think this is a fairly accurate representation of the consensus. This 
leaves the protocol spec in need of an externally specified 
authentication scheme that works for CGI scripts on standard Apache 
configurations.

Robert Sayre

[1] http://www.intertwingly.net/wiki/pie/PaceDigitalSignatures

---

From: Ezra Cooper <[email-masked]>
Date: Wed, 14 Jul 2004 12:17:24 -0700

+1

Authentication should be optional; when it is used, I think it's best 
if we have selected one protocol that implementations SHOULD use. If 
implementations have some specific reason to use another protocol, that 
can still be compliant.

I am working on the 'running code' part of the deal--using some 
variations on Digest.

Ezra

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 11:10:12 -0400

Sam Ruby wrote:

I've scheduled Pace409Response and PaceEntryTopLevel, the first to toss 
the protocol people something to bone, and the second is minor/editorial.

But mostly, and as Tim indicated [1], I tossed "something big, hairy, 
and ugly", namely link/service tags.  This is becoming a bit of a log 
jam.  There are six in all, and frankly if all we achieved was to close 
some and given the others an indication of what they need to address, 
then I would be happy.  I suspect, however, that we can do more: perhaps 
even come to consensus on the concepts expressed in one or more of these 
paces.

Hopefully, we can get into a rhythm with whereby big changes are 
discussed at the beginning of edit cycles and cleanup is done at the end 
of cycles.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07152.html

---

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 11:25:02 -0400

On 16 Jul 2004, at 11:10 am, Sam Ruby wrote:

> jam.  There are six in all, and frankly if all we achieved was to 
> close some and given the others an indication of what they need to 
> address, then I would be happy.  I suspect, however, that we can do 
> more: perhaps even come to consensus on the concepts expressed in one 
> or more of these paces.

There's not a PaceNukeTheLinkTag (and turn each @rel into a new 
element) or equivalent, is there? I think someone needs to write one.

(I started, but found there wasn't clear spec text for each of the rel 
values to include specs for each new element in the Pace - would it be 
alright to write a Pace that just said "Replace [section about the link 
element] with descriptions of each new element as determined by the 
WG"?)

Graham

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 16 Jul 2004 08:43:24 -0700

Greetings again. We got the -00 drafts out last week, and it looks 
like we'll have the -01 drafts published later next week. Even though 
the editors will turn the -01s in over the weekend, it will probably 
take most of the week to get them in the official repository because 
of the last-minute crush before Monday's deadline.

Around IETF meetings, there is a three-week "no drafts" zone. This 
means that no drafts will be accepted by the IETF from 9AM EST on 
Monday until the beginning of the meeting two weeks later, and even 
those turned in during the week of the IETF won't get published until 
after the meeting. The purpose of this so that people can actually 
read the drafts before the meeting without being bombarded with 
truly-last-minute drafts.

Of course, this doesn't mean that we don't need to work during this 
period. The list is having very productive, active discussions about 
the issues that Sam is feeding us from the AtomPubIssuesList. The -02 
drafts will reflect even more changes from these discussions and the 
discussions in San Diego.

However, the fairly strict rule in the IETF is that no decisions are 
ever made at the face-to-face meetings that are not ratified on the 
mailing list. Thus, if we come to some verbal consensus in San Diego 
on some open topics, that will get brought to the mailing list and 
the discussion will continue.

Thus, my guess is that the -02 drafts won't be turned in until about 
a month from now, and possibly later if the post-meeting discussion 
brings up objections that weren't heard in the meeting. It is 
perfectly fine for the drafts to come out in irregular intervals, as 
long as they come out often enough to help the group's discussion 
process move steadily towards completion.

--Paul Hoffman, Director

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 16:05:00 -0500

I've created two wiki pages for aiding the discussion of links.

LinkReferences provides a list of link references, terminology, and
Atom wiki pages discussing links.

LinkingStyles gathers in one place a side-by-side visual comparison of
the linking proposals.

In discussing links, we should be clear on such things as the
"relation name" (what a link with "this" name "means", whether it's in
@rel or the element name) and "relation type" or "relation class"
(what class of links this links falls within: hyperlink, Atom
protocol, display).

For example, PaceServiceElement proposes new elements for the relation
type while maintaining the relation name in an attribute.
PaceReplaceLinkElement proposes using element names for relation
names, but does not distinguish relation types that a client can use
to know how to deal with extensions, particularly those that can or
should be displayed to the user for selection.

  -- Ken