Subject: Comments on atompub-format-08 (Modified by Tim Bray)

From: John Cowan <[email-masked]>
Date: Fri, 22 Apr 2005 12:19:06 -0400

Redirected from John Cowan -Tim
=======================================================

I heard about the Last Call via Ongoing, so I'm going to pester you with
these rather than doing the Right Thing, because at the moment I'm too
swamped to find out what the Right Thing is.  Feel free to squelch any
of these that have been already discussed to death, or to point me to
the Right Thing.

3.2.1:  Allowing only one atom:name in a Person construct is a Bad 
Thing.
Lots of people have different names in different contexts (it's common
for Chinese and Chinese-American people to have distinct Chinese and
English names, e.g.)  Since atom:name is language-sensitive, it should
be repeatable.

4.1.1:  If the order of child elements in an atom:feed element is
meaningless, then it ought to be nailed down by the specification to 
some
fixed arbitrary order (alphabetical or whatever).  Doing that simplifies
processing, eliminates unnecessary differences between semantically
equivalent feed documents, and prevents people from smuggling in 
semantic
information by using some magic ordering of child elements.

4.1.1:  Why require an "alternate" atom:link in an atom:feed?
This implies that a feed can't be the only version of the content:
but conceptually a feed might be completely self-contained, with all
the content right in the feed.  Weaken MUST to SHOULD, I'd say.

4.1.2:  same comment on ordering as 4.1.1.

4.1.3.2:  I have my doubts whether the atom:content@type attribute needs
a SHOULD.  That makes life difficult for people who are repackaging 
other
kinds of feeds or feed-like documents as Atom, because they can't know
the type in the general case without attempting to fetch the content.
Type should be a totally optional hint.

4.1.3.2: The last graf seems totally arbitrary.  What's wrong with
incorporating remote text/plain, text/html, or */*-xml documents by
reference?  In particular, what if they don't yet exist when the feed
is created?  This graf should be removed.

4.2.6 (editorial):  for "SHOULD ... should" read "SHOULD ... SHOULD".

4.2.9 (editorial):  The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove "is an empty element that".

--
John Cowan  [email-masked]  www.reutershealth.com  
www.ccil.org/~cowan
No man is an island, entire of itself; every man is a piece of the
continent, a part of the main.  If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friends or of thine own were: any man's death diminishes 
me,
because I am involved in mankind, and therefore never send to know for
whom the bell tolls; it tolls for thee.  --John Donne

---

From: Graham <[email-masked]>
Date: Fri, 22 Apr 2005 18:19:00 +0100

> English names, e.g.)  Since atom:name is language-sensitive, it should

How would a client app display multiple names?

> information by using some magic ordering of child elements.

Causes unnecessary hassle to implementors. Totally unenforceable.

> is created?  This graf should be removed.

The idea is that wherever possible content is internal. Also, why are 
you proposing advertising the existence of files that don't exist?

Graham

---

From: Antone Roundy <[email-masked]>
Date: Fri, 22 Apr 2005 11:42:43 -0600

> How would a client app display multiple names?

It would choose one based on the user's language preferences or it's 
language capabilities.  I could live with multiple names as long as 
they have a different xml:lang.  I could also live without it, but then 
I'm not Chinese.  I can't imagine many people would use it (other than 
a billion Chinese ;-), so we wouldn't often see it cause clutter.  It 
wouldn't cause any difficulty in consuming feeds that we don't already 
have to deal with with other elements.

I agree with your other comments.

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 13:51:01 -0400

Antone Roundy wrote:
> language capabilities. 

"Since atom:name is language-sensitive, it should be repeatable."

I don't think so. There is nothing stopping someone from defining an 
extension element to handle alternate names.

Robert Sayre

---

From: John Cowan <[email-masked]>
Date: Fri, 22 Apr 2005 13:44:50 -0400

> How would a client app display multiple names?

It could pick one in accordance with the user's language preference,
and optionally display the others through a UI of some sort.

> >some fixed arbitrary order (alphabetical or whatever).  Doing that
> >simplifies processing, eliminates unnecessary differences between
> >semantically equivalent feed documents, and prevents people from
> >smuggling in semantic information by using some magic ordering of
> >child elements.
> 

What unnecessary hassle?  What advantage do implementers get by being
free to generate child elements in a random order?  And as for unenforceable,
it's no more so than any other syntax rule.  Is XML well-formedness enforceable?

> you proposing advertising the existence of files that don't exist?

It decouples the process of creating content from creating feeds.  If
I know I am going to have a chunk of content here, then I can pick a
dereferenceable URI for it and not worry about what the content is
until it's time for both to be published.  As long as the content
exists when the feed is published, all is well.

-- 
John Cowan                                [email-masked]
At times of peril or dubitation,          http://www.ccil.org/~cowan
Perform swift circular ambulation,        http://www.reutershealth.com
With loud and high-pitched ululation.

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 13:54:53 -0400

> it's no more so than any other syntax rule.  Is XML well-formedness enforceable?

I'm not aware of any RSS deployment experience demonstrating that such a 
constraint would be effective.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Fri, 22 Apr 2005 19:08:23 +0100

> and optionally display the others through a UI of some sort.

It's just I've never seen a byline in a newspaper that features more 
than one name, and that's all the author element is there for. You seem 
to be approaching at as providing exhaustive biographical information. 
I don't think it's insensitive to suggest they pick one to be known by 
in a specific context.

> it's no more so than any other syntax rule.  Is XML well-formedness 

How are the two comparable? Badly-formed XML is semantically ambiguous. 
An atom feed with entries or elements in a different order is 
semantically exactly the same. If you tell me (or anyone else) I have 
to memorize and implement an arbitrary order, and are open about it 
achieving exactly nothing, I am going to ignore you.

> exists when the feed is published, all is well.

And why can't you regenerate the feed with content inserted just before 
publishing it? I really don't follow what you're trying to achieve 
here.

Graham Parks

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 14:16:27 -0400

> exists when the feed is published, all is well.

We've had many people speak up about the SHOULD against remote content.

Our own spec covers what consumers should do when it happens, as if to 
acknowledge there are bound to be many situations where producers will 
need to do it.

I suggest we explain the trade-offs and interoperability issues more 
fully, and make it clear that consumers have no obligation to process or 
present remote content in the same manner as local content.

Robert Sayre

---

From: John Cowan <[email-masked]>
Date: Fri, 22 Apr 2005 14:37:39 -0400

> to be approaching at as providing exhaustive biographical information. 

I'm not talking about the atom:author element specifically, but about
Person constructs in general.

> I don't think it's insensitive to suggest they pick one to be known by 

I suppose that that's tolerable, considering that the name is uncontrolled
text anyway.

> semantically exactly the same.

It's semantically the same until someone decides, as I said in my first
email, to attach semantic significance to the order.  If the order is
fixed, that can't happen.

> publishing it? I really don't follow what you're trying to achieve 

The DRY principle is in effect.  Why should the content appear in more
than one place when there is an Atom-blessed way of making it appear
just once?

I'm concerned that if this is a SHOULD, feed consumers won't implement it
or won't implement it properly.

-- 
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"
                John Cowan <[email-masked]>

---

From: John Cowan <[email-masked]>
Date: Fri, 22 Apr 2005 14:38:32 -0400

> present remote content in the same manner as local content.

Fair enough.

-- 
John Cowan  www.ccil.org/~cowan  www.reutershealth.com  [email-masked]
SAXParserFactory [is] a hideous, evil monstrosity of a class that should
be hung, shot, beheaded, drawn and quartered, burned at the stake,
buried in unconsecrated ground, dug up, cremated, and the ashes tossed
in the Tiber while the complete cast of Wicked sings "Ding dong, the
witch is dead."  --Elliotte Rusty Harold on xml-dev

---

From: John Cowan <[email-masked]>
Date: Fri, 22 Apr 2005 14:42:49 -0400

> constraint would be effective.

RSS doesn't impose the constraint, so how could there be implementation
experience there?  There is such experience in the SGML and XML worlds
generally, however.

The general principle is:  If order is significant, the spec needs to be
loose to permit the document creator to choose the correct order.  If
order is not significant, the spec should be tight to reduce pointless
and dangerous variability and simplify validation and processing.

(It's still true that you can put the string "[blue]" anywhere in a
Microsoft Excel cell format to turn it blue, even though the specification
says clearly "at the beginning only", because the implementor used a
general parsing loop to handle it.)

-- 
John Cowan                              <[email-masked]>
http://www.reutershealth.com            http://www.ccil.org/~cowan
                .e'osai ko sarji la lojban.
                Please support Lojban!          http://www.lojban.org

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 14:42:49 -0400

>>present remote content in the same manner as local content.

Oh, and drop the SHOULD, in case I wasn't clear. I fully agree with your 
comments on the relevant sections.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 14:53:58 -0400

> and dangerous variability and simplify validation and processing.

Pointless and dangerous variability is part of life for syndication 
formats, I'm afraid. Defining an order for non-entry elements would be 
sort of like trying to impose order on the HTML <head> element. I 
believe the WG decided such a constraint would be futile. Also, it would 
hurt credibility when trying to enforce more important constraints.

Robert Sayre

---

From: Dan Sandler <[email-masked]>
Date: Fri, 22 Apr 2005 14:49:38 -0500

>>> What advantage do implementers get by being free to generate child 
>>> elements in a random order?
>>
> It's semantically the same until someone decides, as I said in my 
> first email, to attach semantic significance to the order.

It is possible that this has already occurred:

Per section 5.1 of the current draft proposal, Atom feed documents or 
entry documents may be signed (with an enveloped xmldsig signature).  
Once signed, the order of the constituent elements suddenly becomes 
semantically significant: it is the only order for which the signature 
will be valid.

This essentially means that intermediate entities which parse and 
re-emit Atom feed data (such as aggregators or caches) must remember 
"semantically meaningless" details, such as the order of elements, in 
order to re-construct the Atom feed XML in a way that preserves 
signature validity.

> formats, I'm afraid.

If so, then it sounds to me like it is the specification of signed 
documents that needs to be changed (to be tolerant of variable element 
order, as well as other "equivalent" transformations on a document, 
such as different encoding schemes for <atom:content>).

This may be a weakness of the XML-Signatures specification, especially 
when applied to Atom; it appears to me that xmldsig was not designed 
with such "loose" XML document formats in mind.

</de-lurk>

---dan

--
Dan Sandler
Rice University
http://www.cs.rice.edu/~dsandler/

---

From: "Roger B." <[email-masked]>
Date: Fri, 22 Apr 2005 15:06:04 -0500

> What unnecessary hassle?

John: Instead of a user dropping a basic Atom 1.0 template into her
directory, I would need to add special-case code to the underlying app
to get Atom entries into whatever fanciful order the WG settled on.

> What advantage do implementers get by being
> free to generate child elements in a random order?

The order isn't random to the individual implementor. But to put it
simply: re-use of queries.

--
Roger Benningfield
http://admin.support.journurl.com/

---

From: Tim Bray <[email-masked]>
Date: Fri, 22 Apr 2005 13:30:55 -0700

On Apr 22, 2005, at 11:42 AM, Robert Sayre wrote:

>>> fully, and make it clear that consumers have no obligation to 
>>> process or present remote content in the same manner as local 
>>> content.
>> Fair enough.
>
> Oh, and drop the SHOULD, in case I wasn't clear. I fully agree with 
> your comments on the relevant sections.

OK, WG, what do you think?  I have long supported the SHOULD here, but 
I can't help observing that a lot of different parties have questioned 
it, I'm not 100% sure it really has consensus support, even rough.  Rob 
& John's alternative, as outlined above, seems like a fair trade-off 
that would better reflect the community consensus and not really harm 
interoperability.  Anybody want to disagree? -TIm

---

From: Antone Roundy <[email-masked]>
Date: Fri, 22 Apr 2005 14:41:31 -0600

On Friday, April 22, 2005, at 02:30  PM, Tim Bray wrote:
>>>> I suggest we explain the trade-offs and interoperability issues 
>>>> more fully, and make it clear that consumers have no obligation to 
> it, I'm not 100% sure it really has consensus support, even rough.  
> Rob & John's alternative, as outlined above, seems like a fair 
> trade-off that would better reflect the community consensus and not 
> really harm interoperability.  Anybody want to disagree? -TIm
>
I have a very strong preference for local content, but could live with 
the above if it is indeed made "clear that consumers have no obligation 
to process or present remote content".

What does "in the same manner as local content" add?  It suggests that 
consumers might be obligated to present or process it in some other 
way.  I'd rather we say that consumers MAY treat the entry as if 
atom:content were empty if we drop the SHOULD.

Antone

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 17:20:08 -0400

> order to re-construct the Atom feed XML in a way that preserves 

Welcome.

Yes, but only if they wish for the signature to remain valid. The Atom 
spec doesn't require that they preserve signature validity, however.

Your post reminded me that I've made a quick little Atom/DSig demo 
project in NetBeans. There's nothing very special or difficult about it, 
but it took me a while to figure out the XML Security incantations.

Main file:
http://franklinmint.fm/2005/04/22/CreateSignedFeed.java.html

The NetBeans project:
http://franklinmint.fm/2005/04/22/DSigExample.tar.gz

Signed feed:
http://franklinmint.fm/2005/04/22/signed_feed_example.atom

Robert Sayre

---

From: Dan Sandler <[email-masked]>
Date: Fri, 22 Apr 2005 17:03:54 -0500

> spec doesn't require that they preserve signature validity, however.

You're right, the spec doesn't require this.  Should it?  It seems to 
me that signed content is most useful when you have received it from 
some third party instead of the original publisher, and you want to be 
sure it hasn't been tampered with.

These mysterious third parties are currently rare, but that may not be 
the case forever.  There are already a number of "feed republishers" 
(e.g., FeedBurner) which would need to preserve the validity of feed 
signatures.  Viewed more broadly, any Atom-consuming toolkit which also 
emits Atom as output (e.g., Rome) would need to pay attention to 
ordering in order to preserve feed signatures; the spec does not 
currently require them to do this.

[Another example is my current research project, FeedTree[1].  It uses 
a decentralized event notification system to distribute RSS and Atom 
data among interested peers, thereby reducing bandwidth demands on 
publishers and improving promptness of service for end users.  In order 
to establish the authenticity of an Atom entry it has received, each 
FeedTree node would like to verify the publisher's signature on that 
item.  Some intermediate node might shuffle the order of elements (as a 
result, say, of parsing the feed and re-emitting it); it has done 
nothing "wrong" within the Atom specification and yet the signature is 
broken.  For the purposes of FeedTree I'm able to sidestep this issue 
by using a predictable ordering within the system, but it would be nice 
if a node were able to take a "wild" signed Atom document and inject it 
*into* the system in a way that doesn't break signatures.]

[1] http://www.cs.rice.edu/~dsandler/pub/FeedTree-IPTPS05-draft.pdf

---dan

---

From: Antone Roundy <[email-masked]>
Date: Fri, 22 Apr 2005 16:25:07 -0600

> order to re-construct the Atom feed XML in a way that preserves 
More issues: What happens when a signed entry contains foreign markup 
(aka elements from some other namespace)?  If there's just one and we 
specify a location in the sequence for foreign markup, we're safe, but 
what if there are two?  What about when an Atom element is duplicated 
(eg. the titles in two languages, two contributors).  Are we going 
specify the order of attributes on elements?  (Does that affect the 
signature?)  What about extension attributes on Atom elements?  If we 
can't solve all of these, do we care to solve some of them?

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Apr 2005 15:28:08 -0700

At 5:03 PM -0500 4/22/05, Dan Sandler wrote:
>>>re-emit Atom feed data (such as aggregators or caches) must 
>>>remember "semantically meaningless" details, such as the order of 
>>>elements, in order to re-construct the Atom feed XML in a way that 
>>>preserves signature validity.
>>
>>Yes, but only if they wish for the signature to remain valid. The 
>>Atom spec doesn't require that they preserve signature validity, 
>>however.
>
>You're right, the spec doesn't require this.  Should it?

No. A signature is only significant from the signer, not anyone else 
who touches any of the bits. If you want to touch any of the bits 
(even just disassembling and reassemling), assume the signature will 
be broken.

>   It seems to me that signed content is most useful when you have 
>received it from some third party instead of the original publisher, 
>and you want to be sure it hasn't been tampered with.

If so, then the third party must handle it as an opaque blob.

>These mysterious third parties are currently rare, but that may not 
>be the case forever.  There are already a number of "feed 
>republishers" (e.g., FeedBurner) which would need to preserve the 
>validity of feed signatures.  Viewed more broadly, any 
>Atom-consuming toolkit which also emits Atom as output (e.g., Rome) 
>would need to pay attention to ordering in order to preserve feed 
>signatures; the spec does not currently require them to do this.

They need to pay attention to much more than just the order of the 
entries to make sure the signature is valid. Every bit, and every 
bit's order, counts.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Tim Bray <[email-masked]>
Date: Fri, 22 Apr 2005 15:50:03 -0700

> entries to make sure the signature is valid. Every bit, and every 

Actually, not really.  I think XML DSig specifies canonical XML 
(right?), so

  <hello to="world"/>
and
  <hello to='world></hello>

will end up with the same DSIG.

But element order *does* matter. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 19:01:33 -0400

> Actually, not really.  I think XML DSig specifies canonical XML 

Yes,

>  <hello to="world"/>
> and
>  <hello to="world"></hello>
> 
> But element order *does* matter.

that's correct, but changing

   <entry>
     <title>Atom draft-07 snapshot</title>

to

   <entry><title>Atom draft-07 snapshot</title>

will invalidate the signature, so there are requirements in excess of 
element order, as far as Atom is concerned.

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 25 Apr 2005 00:56:42 -0400

John Cowan wrote in response to Graham:
> It decouples the process of creating content from creating feeds.
> If I know I am going to have a chunk of content here, then I can
> pick a dereferenceable URI for it and not worry about what the content
> is until it's time for both to be published.  As long as the content
	A slightly different case, but instructive: At PubSub, we have a
situation where we regularly publish data in Atom feeds even though the
"alternate" pages aren't yet available on the network.
	This happens constantly with our Earthquake feeds[1]. While each
entry we publish has most of the relevant information on an earthquake, each
entry also points to pages on the USGS site. The USGS pages provide
augmented information concerning the earthquake event in HTML. The problem
is that we regularly publish entries in our feeds at least 15 seconds before
and sometimes a few minutes before the corresponding pages are available on
the USGS site. Their content management system is a bit slower then ours
is... What we've had to do is get the USGS folk to change their "page not
found" message so that it says: "The webpage you are looking for has either
moved or may still be in preparation if it describes a recent earthquake."
You can see this message at: 
http://earthquake.usgs.gov/recenteqsUS/Quakes/nosuchpage.htm
	Most polling-based readers will not, of course, ever come across
this timing problem since their polling frequencies are vastly larger then
the 15 second normal publication delay. However, users of push-based Atom
readers (like the "Atom over XMPP" based Sidebars[2] that we supply to
PubSub users) will often see and click on a new Atom entry from PubSub
within two to three seconds of our having published the entry. (Yes, this
makes this an edge case; however, as push-based consumption of Atom
increases, it will become more common.)
	Admittedly, publishing real-time, volatile data is not yet a common
usage of Atom and push-based Atom consumers are still not common. However, I
think we're going to see more of this in the future. Certainly, we at PubSub
expect to generate more such feeds and we're certainly going to try to get
more people using push-protocols. The difficulty is that delaying publishing
until all the alternates or referenced URIs are known to exist imposes
unacceptable constraints on the system. With data like Earthquake or Tsunami
notices, we should *not* be delaying the publishing of messages simply to
conform to the specification...

	bob wyman

[1] http://www.pubsub.com/earthquakes.php
[2] http://www.pubsub.com/downloads.php

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 25 Apr 2005 02:17:23 -0400

Graham Parks wrote:
> It's just I've never seen a byline in a newspaper that features
> more than one name, and that's all the author element is there for.

See: Rice and Cheney Are Said to Push Iraqi Politicians on Stalemate
By RICHARD A. OPPEL Jr. and JOEL BRINKLEY  
http://www.nytimes.com/2005/04/25/international/middleeast/25iraq.html?

See: "Blogs Will Change Your Business"
By Stephen Baker and Heather Green
http://businessweek.com/magazine/content/05_18/b3931001_mz001.htm

That's one example from a newspaper and one from a magazine. Now, you've
seen something that you've never seen before!

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 25 Apr 2005 02:54:34 -0400

> order to re-construct the Atom feed XML in a way that preserves 
	One other *significant* limitation in Atom's support for signatures
is that there is no way for an intermediary to add to or otherwise modify an
Atom entry without breaking the signature. What this means is that
intermediaries like PubSub, if they modify an entry by adding content,
repairing broken syntax, or normalizing character sets will be forced to
remove the original signature and insert a new signature issued by the
intermediary. Similar issues will arise in any case where someone copies a
signed Atom entry from one feed to another. Unless the copying is done in
such a way that it doesn't disturb the canonicalized form of the entry, the
original signature will be invalidated.
	There are numerous other issues relating to signed Atom documents
that we've decided (somewhat unwisely...) to punt until after the core
document is released. The existing signature support is vitally important to
have in the core, however, I feel it really *must* be expanded upon
extensively in future extensions.

	bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Mon, 25 Apr 2005 17:18:36 +1000

> seen something that you've never seen before!

Those are examples of multiple authors, not of singular authors with
multiple names. Different issue.

Not to say multiple authors (not contributors) is not another issue.

e.

---

From: Graham <[email-masked]>
Date: Mon, 25 Apr 2005 09:45:48 +0100

> http://businessweek.com/magazine/content/05_18/b3931001_mz001.htm

Those are different people aren't they? The topic was more than one 
name for the same person. Never mind Bob.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Apr 2005 09:23:31 -0400

Bob Wyman wrote:

> Atom entry without breaking the signature.

If people want to send out signed entries with an XPath filter[0] that 
gives intermediaries a place to put things, there's nothing stopping 
them. If they don't want PubSub or equivalent to touch a single bit, 
that's their prerogative.

Robert Sayre

[0] http://www.w3.org/TR/xmldsig-filter2/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Apr 2005 08:26:36 -0700

>Atom entry without breaking the signature.

That's a purposeful design property of digital signatures. The exact 
same issue has long affected secure mail forwarders using S/MIME or 
OpenPGP.

>  What this means is that
>intermediary.

Right. The intermediary can, however, add a signed extension that 
says "this message was earlier signed by Xyzzy, and we verified that 
signature before we changed things." If the recipient trusts your 
signature, they also must trust your attestation that you verified 
the earlier signature.

>extensively in future extensions.

Given that this is IETF Last Call, such issues are appropriate, and 
may delay us from getting a standard if the Security ADs bring them 
up. Can you list them? If they are Atom-specific, we can consider 
them; if they are generic to XMLDigSig, we probably have to punt (but 
will want to report them in the Security Considerations section of 
the draft).

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 26 Apr 2005 22:02:48 -0400

Paul Hoffman wrote:
> The intermediary can, however, add a signed extension that 
> signature before we changed things."
	Forgive me if I'm missing something obvious... While I understand
that such a statement could be generated in theory, it is not obvious to me
what the precise syntax for writing such a statement would be given just
what is said about signatures in the Atom draft. It seems to me that we
would have to either adopt additional syntax from some currently
not-referenced spec, or we'd have to define a new extension. What would you
propose is the correct way to get interoperable statements such as the ones
you suggest in your note? 

>> is that there is no way for an intermediary to add to or otherwise modify
>> an Atom entry without breaking the signature.
	But, the problem is slightly less painful in S/MIME applications
since you can wrap a signed message in an attachment while providing
additional data in the envelope. Atom doesn't provide a similar mechanism.

		bob wyman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Apr 2005 19:19:49 -0700

>you suggest in your note?

The latter (an extension). Sorry if I didn't make that clear.

>additional data in the envelope. Atom doesn't provide a similar mechanism.

Correct, but the pain is certainly still there for S/MIME and OpenPGP.

--Paul Hoffman, Director