On Tue, 28 Jun 2005 03:21:19 +0200, James Cerra [EMAIL PROTECTED]
wrote:
I knew that, but I was unaware of how un-updatable a step that was. I
apologize for my ignorance.
The same goes for me.
No. I thought that there was room for updates to the draft during IESG
consideration. That
I wanted to point out that comments I've made on the
application/atom+xml media type registration template have not yet been
incorporated into the syntax draft, nor have I received any feedback
about why they needn't be.
These are not show-stoppers by any means, but are also not exactly
* Mark Nottingham [EMAIL PROTECTED] [2005-07-01 20:55]:
How do you figure that? HTTP delta encoding is a generic
mechanism layered into HTTP; if you do a bare GET against a
resource, the server has to return the whole representation.
[…]
Where does it talk about this in RFC3229? A
On 7/5/05, Mark Baker [EMAIL PROTECTED] wrote:
I wanted to point out that comments I've made on the
application/atom+xml media type registration template have not yet been
incorporated into the syntax draft, nor have I received any feedback
about why they needn't be.
See comments from Tim
At 9:41 PM -0700 7/4/05, Tim Bray wrote:
On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote:
I believe it would be very useful to specify that signed entries
should include a source element. This can/should be considered
part of entry canonicalization.
-1. Leave it to the market. I
Paul Hoffman wrote:
I'm with Tim on the -1. Bob's suggestion and explanation make
good sense for the implementer's guide, but not for the base spec.
There is not an interoperability issue that I can see for entries
without sources being signed.
Could we at least put in a sentence
On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote:
We can debate what it means to have an interoperability issue,
however, my personal feeling is that if systems are forced to break
and
discard signatures in order to perform usual and customary
processing on
entries that falls very close to
Paul Hoffman wrote:
The root of an Atom document (i.e., atom:feed in an Atom Feed
Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
Signature, as described by XML-Signature and Syntax Processing
[W3C.REC-xmldsig-core-20020212].
Are we going to be making the
On Tue, Jul 05, 2005 at 10:33:00AM -0400, Robert Sayre wrote:
On 7/5/05, Mark Baker [EMAIL PROTECTED] wrote:
I wanted to point out that comments I've made on the
application/atom+xml media type registration template have not yet been
incorporated into the syntax draft, nor have I
Tim Bray wrote:
On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote:
We can debate what it means to have an interoperability issue,
however, my personal feeling is that if systems are forced to break and
discard signatures in order to perform usual and customary
processing on
entries that
At 9:16 AM -0700 7/5/05, James M Snell wrote:
Are we going to be making the change specified in point 1 of [1] ?
That is, specifically allow for Signature on any atom:entry element?
Yipes! Good catch. That was my mistake. I rolled-up from one thread,
not both of them.
The beginning of 5.1
On Tuesday, July 5, 2005, at 10:11 AM, Tim Bray wrote:
On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote:
We can debate what it means to have an interoperability issue,
however, my personal feeling is that if systems are forced to break
and
discard signatures in order to perform usual and
On Jul 5, 2005, at 9:27 AM, James M Snell wrote:
Huh?! Pardon my ignorance, could you please provide an
explanation for the simple-minded as to how the absence of a
source element in a signed entry will lead to signatures being
discarded? Also, it would be helpful to sketch in some of
Tim Bray wrote:
If I want to sign an entry and also want to make it available
for aggregation then yes, I'd better put in an atom:source. But
this is inherent in the basic definition of digsig; not something
we need to call out. -Tim
Certainly, the chain of reasoning is as clear
Antone Roundy wrote:
When signing individual entries that do not contain an
atom:source element, be aware that aggregators inserting an
atom:source element will be unable to retain the signature. For this
reason, publishers might consider including an atom:source element in
all
Tim Bray wrote:
Still -1, despite Bob's arguments, at least in part because we have
no idea what kind of applications are going to be using signed
entries and we shouldn't try to micromanage a future we don't
understand. -Tim
We *DO* know that PubSub will support signed entries in the
At 2:24 PM -0400 7/5/05, Bob Wyman wrote:
I find it hard to imagine what harm could be done by providing this
recommendation.
Timing. If we change text other than because of an IESG note, there
is a strong chance we will have to delay being finalized by two
weeks, possibly more.
* Bob Wyman [EMAIL PROTECTED] [2005-07-05 19:30]:
Antone Roundy wrote:
When signing individual entries that do not contain an
atom:source element, be aware that aggregators inserting an
atom:source element will be unable to retain the signature. For this
reason, publishers might
Paul Hoffman wrote:
At 2:24 PM -0400 7/5/05, Bob Wyman wrote:
I find it hard to imagine what harm could be done by providing this
recommendation.
Timing. If we change text other than because of an IESG note, there is
a strong chance we will have to delay being finalized by two
Paul Hoffman wrote:
Timing. If we change text other than because of an IESG note,
there is a strong chance we will have to delay being finalized by
two weeks, possibly more.
I am aware of the issues with timing and I believe I am just as
concerned as you are with these issues. I was
On 7/5/05, Bob Wyman [EMAIL PROTECTED] wrote:
Tim Bray wrote:
Still -1, despite Bob's arguments, at least in part because we have
no idea what kind of applications are going to be using signed
entries and we shouldn't try to micromanage a future we don't
understand. -Tim
-1 as well.
--On Tuesday, July 05, 2005 11:48:44 AM -0700 Paul Hoffman [EMAIL PROTECTED]
wrote:
At 2:24 PM -0400 7/5/05, Bob Wyman wrote:
I find it hard to imagine what harm could be done by providing this
recommendation.
Timing. If we change text other than because of an IESG note, there is a
On Jul 5, 2005, at 12:50 PM, Walter Underwood wrote:
I'm fine with the delay. Two or three weeks on top of 18 months is
not a big deal.
I am *not*. It's not two or three weeks, it's some
uncontrollable time in the future versus now. We have spent way
too long already. -Tim
It's been raised before [1] [2], but can we clarify whether a MIME
type in atom:content etc. can contain parameters or not?
MIME is a bit vague about the definition of what a mime type is, and
historically applications have been tripped up by unexpected MIME
parameters.
Can we add something
On Tuesday, July 5, 2005, at 01:09 PM, A. Pagaltzis wrote:
* Bob Wyman [EMAIL PROTECTED] [2005-07-05 19:30]:
Antone Roundy wrote:
When signing individual entries that do not contain an
atom:source element, be aware that aggregators inserting an
atom:source element will be unable to retain
Tuesday, July 5, 2005, 5:09:40 PM, Paul Hoffman wrote:
At 11:58 AM -0400 7/5/05, Bob Wyman wrote:
Could we at least put in a sentence that states that including a
source element in signed entries is recommended? The implementer's guide
would then expand on that with more detail,
Antone Roundy wrote:
On Tuesday, July 5, 2005, at 01:09 PM, A. Pagaltzis wrote:
* Bob Wyman [EMAIL PROTECTED] [2005-07-05 19:30]:
Antone Roundy wrote:
When signing individual entries that do not contain an
atom:source element, be aware that aggregators inserting an
atom:source element
On Jul 5, 2005, at 1:05 PM, David Powell wrote:
Will we still be fixing some of bugs raised since the last draft
though?
Definitely. A number of things have been pointed out as bugs,
there's been no WG pushback on any of them, and since we were going
to have to have a -10 draft anyhow
Antone Roundy wrote:
On Tuesday, July 5, 2005, at 10:11 AM, Tim Bray wrote:
On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote:
We can debate what it means to have an interoperability issue,
however, my personal feeling is that if systems are forced to break and
discard signatures in order
How about a compromise on the source insertion thing...
Paul Hoffman's proposed text for the first paragraph in Section 5 starts off
with a set of examples of why one would want to sign or encrypt atom entries
or feeds. (Discount coupons, bank statements, etc.) These examples were
requested by
OK, I'm backing off of my statement that it is too late to deal with
this. Thank you to the people who pointed out that this is directly
related to Russ' concern about interop of canonicalization. You are
right, and I was being too narrow-minded.
Does anyone object to the following exact
Paul Hoffman wrote:
OK, I'm backing off of my statement that it is too late to deal with
this. Thank you to the people who pointed out that this is directly
related to Russ' concern about interop of canonicalization. You are
right, and I was being too narrow-minded.
Does anyone object to
On Jul 5, 2005, at 4:08 PM, Paul Hoffman wrote:
Intermediaries such as aggregators may need to add an atom:source
element to an entry that does not contain its own atom:source
element. If such an entry was signed, the addition will break the
signature. Thus, a publisher of
Paul Hoffman wrote:
Intermediaries such as aggregators may need to add an
atom:source element to an entry that does not contain its own
atom:source element. If such an entry was signed, the addition
will break the signature. Thus, a publisher of individually-signed
entries should strongly
34 matches
Mail list logo
