At 8:16 AM -0500 2/23/07, Elliotte Harold wrote:
By the way, http://www.iana.org/assignments/relation/ is 404. This
is referenced in the Atom 1.0 spec. It doesn't really need to be
resolved, but it would be nice to put something there.
It doesn't need to be resolved at all. Given the
At 4:41 PM +0900 12/13/06, Martin Duerst wrote:
At 13:14 06/12/13, James M Snell wrote:
I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.
The dot is used for prefixes like vnd. (vendor) and so on.
In
Because of his recent ad hominem attacks, I have temporarily
suspended Robert Sayre's posting privileges for the two Atompub WG
mailing list for 30 days, as specified in RFC 3934. If you have
questions or comments about this action, please first take them to
Tim and me offline.
At 4:56 PM -0500 11/28/06, Robert Sayre wrote:
James M Snell wrote:
Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established. What would be excellent is if you'd give others the
opportunity to weigh
At 6:16 PM -0500 11/28/06, Robert Sayre wrote:
On 11/28/06, Rogers Cadenhead [EMAIL PROTECTED] wrote:
I have no idea how to gauge the
likelihood they'll achieve it. Or whether they'll
respect current autodiscovery functionality in MSIE 7
and Firefox 2.0.
My experience is that the IETF is
At 9:48 PM +0100 11/18/06, A. Pagaltzis wrote:
If future changes can be made in a backward-compatible
fashion, they will go into a spec that recycles the same
namespace. Existing implementations can just ignore the
differences.
If they cannot, they will go into a spec which revs the
namespace,
At 1:32 PM -0800 11/3/06, James M Snell wrote:
Cool thx. I'll watch for it following the IETF meeting.
Actually, the window opens again the first day of the meeting (Monday).
At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up
any errata and adding two attributes: 'dir' and 'unicode-bidi', as
defined in XHTML.
We can't both add features and move to Draft Standard at the same
time. If we add features,
At 11:17 AM -0400 10/2/06, Robert Sayre wrote:
Paul Hoffman wrote:
At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up
any errata and adding two attributes: 'dir' and 'unicode-bidi', as
defined in XHTML.
We can't both add
At 6:23 PM + 10/2/06, Robert Sayre wrote:
That's unfortunate. A documented process is a requirement for open standards
development, in the opinion of many
If it is a true requirement, then I guess the IETF is an abysmal
failure. Oh, well.
OTOH, some folks in the IETF are trying to meet
... are at http://www3.ietf.org/proceedings/06jul/minutes/atompub.txt
--Paul Hoffman, Director
--Internet Mail Consortium
half of the commenters, interupted only by
incorrect readings of RFC2026 and obfuscation by the document author.
Your reading might differ from others'.
--Paul Hoffman, Director
--Internet Mail Consortium
or other interested
parties.)
--Paul Hoffman, Director
--Internet Mail Consortium
At 1:49 PM -0700 5/23/06, Paul Hoffman wrote:
Greetings again. The Atompub WG will have our first (and maybe
last!) face-to-face meeting at the upcoming IETF meeting in Montreal
at the beginning of July.
The timing of us having our first WG meeting may seem odd, given the
fact that we
for details about the
IETF meeting. I will let the WG know when there are preliminary and
near-permanent agendas for the meeting. It would be good to meet some
of you there!
--Paul Hoffman, Director
--Internet Mail Consortium
; for others, just a bother. We
won't know where the Atom format fits in that range for a few years.
--Paul Hoffman, Director
--Internet Mail Consortium
.
That can be arranged for the weekend before; I'll be in Montreal
early. Depending on the number of people, we could just get together
in a hallway somewhere, or maybe in someone's Montreal office, or
something.
--Paul Hoffman, Director
--Internet Mail Consortium
in the way Joe predicted. Time for
a revision.
I'm confused. What breaks?
--Paul Hoffman, Director
--Internet Mail Consortium
mailing
lists.
You don't have to listen to the WG, but if one or two WG members are
going to deploy and then standardize whatever they've done, that's an
informational document.
That is not true. If it is a protocol or a format, standards track is
also appropriate.
--Paul Hoffman, Director
or not the document is ready to be an
RFC, regardless of the type of RFC it will become.
--Paul Hoffman, Director
--Internet Mail Consortium
At 8:55 AM -0800 3/7/06, Walter Underwood wrote:
Don't use x-, either. Register a real type.
+1
--Paul Hoffman, Director
--Internet Mail Consortium
There has been a surprisingly small number of posts about these
Paces. Or milestone is drifting into the barely-seeable past. More
comments on the Paces, sooner rather than later, would be appreciated.
--Paul Hoffman, Director
--Internet Mail Consortium
.
That's true. And it matches the XML 1.0 spec exactly.
--Paul Hoffman, Director
--Internet Mail Consortium
standard by its RFC number, but instead by its
extension name.
Having said all that, please review any extension documents carefully
and post your responses to the mailing list. This helps both the
author and the IETF decide whether to make them standards.
--Paul Hoffman, Director
--Internet Mail
not? From the publisher's point of view, an intermediary
aggregator like PubSub should be indistinguishable from the channel itself.
+1 to Bob's comments. I can see reasons why I would want my firmware
updates aggregated through an intermediary.
--Paul Hoffman, Director
--Internet Mail Consortium
where this feed
was originally grabbed from?
--Paul Hoffman, Director
--Internet Mail Consortium
at the feed level (as
compared to in entries) indicate:
a) this information pertains to each entry
b) this information pertains to the feed itself
c) this information pertains to each entry and to the feed itself
d) completely unknown unless specified in the extension definition
--Paul Hoffman
to the feed itself (unless otherwise specified)
c) this information pertains to each entry and to the feed itself
(unless otherwise specified)
d) completely unknown unless specified in the extension definition
--Paul Hoffman, Director
--Internet Mail Consortium
level?
--Paul Hoffman, Director
--Internet Mail Consortium
of the introductory text to Common Atom Constructs) we add:
Note that there MUST be no whitespace in a Date construct or in any
IRI. Some XML-emitting implementations erroneously insert whitespace
around values by default, and such implementations will emit invalid
Atom.
--Paul Hoffman, Director
--Internet
leading and/or trailing whitespace, such as IRIs and .
--Paul Hoffman, Director
--Internet Mail Consortium
At 11:43 AM +0100 8/4/05, Bill de hÓra wrote:
Paul Hoffman wrote:
At 7:37 PM -0400 8/2/05, Robert Sayre wrote:
One way of saying this would be Atom Processors MAY ignore leading
and trailing whitespace in _.
That works for me. Another idea is Atom Processors MAY ignore
string that has whitespace around it),
should you fail immediately or try harder? I propose trying harder,
but I am open to just fail.
--Paul Hoffman, Director
--Internet Mail Consortium
is a reasonable way to do things even if the resolution breaks
at some point, as long as there is a longer-lived source of a copy of
what the description was.
--Paul Hoffman, Director
--Internet Mail Consortium
are made
to the draft. This is definitely lighter-weight, but much more likely
to bring bad feelings and lack of consensus unless the draft authors
are really good at listening. Still, it is easy to do.
--Paul Hoffman, Director
--Internet Mail Consortium
in the Security Considerations section.
And, the two Security Area Directors have signed off on the Security
Considerations section in -10.
--Paul Hoffman, Director
--Internet Mail Consortium
[[ Be sure to send comments to the list below, not to the Atompub WG list. ]]
From: Randy Presuhn [EMAIL PROTECTED]
To: Working Group Chairs [EMAIL PROTECTED]
Date: Thu, 14 Jul 2005 16:42:54 -0700
Hi -
Language tags are used in many applications and protocols, so
we'd like to get as broad a
feature/behaviour but it seems
something like a flag that you have to give.
Agree.
--Paul Hoffman, Director
--Internet Mail Consortium
the outside?
It may be helpful to give guidance about the usage of the
InclusiveNamespaces PrefixList, especially with default namespaces.
The whole purpose of using exclusive XML is to not need to guess
about what is and is not in the bag of bits being hashed.
--Paul Hoffman, Director
--Internet Mail
At 1:56 PM -0400 7/7/05, Mark Nottingham wrote:
On 07/07/2005, at 11:36 AM, Paul Hoffman wrote:
At 10:23 AM -0400 7/7/05, Mark Nottingham wrote:
Are we specifying exclusive c14n with or without comments? My
preference would be without.
Without. That is explicitly the default for
http
see for entries without
sources being signed.
--Paul Hoffman, Director
--Internet Mail Consortium
Processing
[W3C.REC-xmldsig-core-20020212].
--Paul Hoffman, Director
--Internet Mail Consortium
.
--Paul Hoffman, Director
--Internet Mail Consortium
of individually-signed entries should
strongly consider adding an atom:source element to those entries
before signing them.
--Paul Hoffman, Director
--Internet Mail Consortium
the identity of the entity
that signed the document. Note that, if MACs are used for authentication,
the order MUST be that the signed document is encrypted, and not the
other way around.
--Paul Hoffman, Director
--Internet Mail Consortium
At 4:44 PM +0900 7/1/05, Martin Duerst wrote:
At 10:26 05/07/01, Paul Hoffman wrote:
To be added near the end of Section 5.1 of atompub-format:
Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support
for Canonical XML. Atom Processors that sign Atom Documents MUST
use
At 1:45 PM -0700 7/1/05, James M Snell wrote:
Paul Hoffman wrote:
Unfortunately, the complexity of XML and the variety of contexts in
which it is used made it impossible for the XMLDSIG WG to come up
with one set of canonicalization rules that are distinguished.
By distinguished, I
can't
assume anything about the bits; if it does, the other semantic data
in the message can apply to them (...and it is a picture of me,
...and it is a program that will delete your data...).
--Paul Hoffman, Director
--Internet Mail Consortium
without a lot of additional words and a different type of
signature.
Suggestion (and only a suggestion): don't go there.
--Paul Hoffman, Director
--Internet Mail Consortium
properly.
--Paul Hoffman, Director
--Internet Mail Consortium
At 1:42 PM +0200 6/27/05, Asbjørn Ulsberg wrote:
I guess we won't be nuking the atom:uri element before Atom goes gold?
Correct.
--Paul Hoffman, Director
--Internet Mail Consortium
that we pull the spec back
from the IESG, make this change, and then ask them to look again? Or
something else I'm missing?
--Paul Hoffman, Director
--Internet Mail Consortium
voting, they can.
Stay tuned, and it won't be that long until we know for sure.
--Paul Hoffman, Director
--Internet Mail Consortium
is a
bummer for anxious implementers. I guess I'm just used to much worse
things happening in the IESG in the past, like really long delays.
--Paul Hoffman, Director
--Internet Mail Consortium
At 10:32 AM -0700 6/22/05, James M Snell wrote:
Paul Hoffman wrote:
2) What you are signing is just the set of bits in the entry, or
just the set of bits in the feed, with no interpretation of them.
No pre-canonicalization is needed, and none is to be expected by
the validating party.
I
the entry.
Such a document would probably be useful, or it might just be a
useful entry in the implementer's guide. Getting input from some
currently-active aggregators would be really useful for that, of
course.
--Paul Hoffman, Director
--Internet Mail Consortium
are expressly encouraged at this time. That is not to
say let's start adding a bunch of needless extensions and
provisions, but certainly I see a need and I think I might propose
a solution is a Very Good Thing for this list.
--Paul Hoffman, Director
--Internet Mail Consortium
://www.intertwingly.net/wiki/pie/FrontPage).
--Paul Hoffman, Director
--Internet Mail Consortium
in Appendix A after the IESG
review. Please respond to me off-list. Thanks!
At 1:23 PM -0700 5/19/05, Paul Hoffman wrote:
Greetings again. The nearly-nearly-complete format draft has a short
list of contributors in Appendix A. This WG has been phenomenally
active, and much of that activity
with the document
during their review.
--Paul Hoffman, Director
--Internet Mail Consortium
;
if so, then I guess that ambiguities might be considered to be bugs,
that still need fixing.
There is a large difference between suggesting a bunch of reworking
and pointing out specific ambiguities. Please do the latter if you
find them.
--Paul Hoffman, Director
--Internet Mail Consortium
-Encoding: gzip header should be uncompressed in situ
*before* it is extracted from the multipart envelope.
That doesn't make any sense.
+1
--Paul Hoffman, Director
--Internet Mail Consortium
secret, so I'd think it should be required.
This is the kind of thing we can do in the implementer's guidelines.
It doesn't solve the chain-of-trust problem, though.
Nothing does :-) . Or is that :-( ?
--Paul Hoffman, Director
--Internet Mail Consortium
signed feeds and entries should do.
--Paul Hoffman, Director
--Internet Mail Consortium
be to have multiple identities associated
with keys. My key might be identified with Paul Hoffman and
http://lookit.proper.com; and http://saladwithsteve.com/osx/; and
so on.
Another interesting question would be what is that role of
intermediaries like PubSub or search engines in signing
and facilitate the
interchange or translation of documents between NewsML, NITF, etc.
formats and Atom.
The IETF can't formally do this, but wearing my co-chair hat I'll
happily +1 that.
--Paul Hoffman, Director
--Internet Mail Consortium
.../
/link
I read empty as always empty, so the XML novice in me would say
that the above expression in inherently wrong.
--Paul Hoffman, Director
--Internet Mail Consortium
-like seems fairly out-of-scope for an IETF WG.
Could you clarify?
--Paul Hoffman, Director
--Internet Mail Consortium
responses sound a great deal
like we should be making changes to our documents based on W3C test
guidelines. For what purpose?
--Paul Hoffman, Director
--Internet Mail Consortium
. The former makes good guesses about
HTMLizing, but may have errors introduced by the automated guessing
process.
--Paul Hoffman, Director
--Internet Mail Consortium
.
That was the IETF-wide last call, last month. The announcement was
made on the IETF-Announce mailing list, and brought in a few folks.
In addition, Tim and I pestered a number of people we know who we
thought might not be following the document and asked them to look in.
--Paul Hoffman, Director
made the basic spec much stronger and
more complete than any individually-submitted RFC could possibly be.
Why shouldn't the IETF close this WG down?
Because it is still improving on a specification that is important to the IETF.
--Paul Hoffman, Director
--Internet Mail Consortium
wording because the phrase that
Bob removes is impossible to measure or enforce, but Bob's wording is
cleaner for the same result.
--Paul Hoffman, Director
--Internet Mail Consortium
with
that isn't inherently signed has either this exact problem or one
very close to it. The fact that the format document specifies a
signing mechanism in the document itself instead of in a companion
document that is read by only 25% of the implementers is a giant leap
forward.
--Paul Hoffman, Director
element, no other parts of the entry. If we took this
too the extreme Rob wants, we would have to allow completely null
entries because titles, dates, and even IDs could be considered
content.
--Paul Hoffman, Director
--Internet Mail Consortium
.
--Paul Hoffman, Director
--Internet Mail Consortium
there really is no
summary, then title-only feeds are fine.
--Paul Hoffman, Director
--Internet Mail Consortium
At 1:07 PM -0600 5/12/05, Antone Roundy wrote:
On Thursday, May 12, 2005, at 12:32 PM, Julian Reschke wrote:
Paul Hoffman wrote:
At 7:16 PM +0200 5/12/05, Julian Reschke wrote:
A receiving implementation must be able to handle all defined
elements, regardless if they are defined as MAY sent
the XML
rules would be very good right about now...
--Paul Hoffman, Director
--Internet Mail Consortium
At 9:45 AM -0400 5/11/05, Robert Sayre wrote:
On 5/11/05, Danny Ayers [EMAIL PROTECTED] wrote:
Marketing: Atom
Technical: Atom (RFC)
+1
Hmm. I forgot one little detail. It might take like 4-6 months to get
an RFC number after IESG approval.
s/might/probably will/
--Paul Hoffman
At 9:09 PM -0700 5/9/05, Walter Underwood wrote:
Seriously, I don't mind Atom 1.0 as long as the next version is
Atom 2.0.
+12
--Paul Hoffman, Director
--Internet Mail Consortium
grossly technically inaccurate, unless you consider every
written language other than Chinese, Japanese Kanji, Burmese, Khmer,
Thai, Tagalog, Lao, and Tibetan to be English. (The folks who speak
all the other languages might find you calling them English to be
insulting too, of course.)
--Paul
with your proposed pipe that you don't need to care about the
issue.
I'll make that response. :-)
--Paul Hoffman, Director
--Internet Mail Consortium
2822 as well.
--Paul Hoffman, Director
--Internet Mail Consortium
wrote:
Fair enough. But can just anyone add stuff to the Atom namespace?
If the IESG lets them, yes.
We gotta trust the IESG after the WG shuts down. Fortunately, they
have earned that trust over time.
--Paul Hoffman, Director
--Internet Mail Consortium
support the latter because, as
you posit, people will disagree on how they should be able to assert
rights. Coming up with a single extension structure that will keep
everyone happy will take a lot of wrangling, but the effort would
probably be worth it.
--Paul Hoffman, Director
--Internet Mail
-1. Having two mechanisms in two different layers is a recipe for
disaster. If HTTP headers are good enough for everything else on the
web, they're good enough for Atom.
--Paul Hoffman, Director
--Internet Mail Consortium
Expect to see at least a couple of more duplicates of recent messages
on the list. This one comes courtesy of Xerox. The offending user has
been removed from the mailing list and been told of the problem.
--Paul Hoffman, Director
--Internet Mail Consortium
traffic in the past week.
--Paul Hoffman, Director
--Internet Mail Consortium
avenue to
erase an old entry, why wouldn't they try this as well?
--Paul Hoffman, Director
--Internet Mail Consortium
At 6:47 PM +0100 4/27/05, Graham wrote:
On 27 Apr 2005, at 5:28 pm, Paul Hoffman wrote:
Proposal for thinking about: to simplify the spec, atom:summary
should either be a MUST in all cases or a MAY in all cases. If it
is just semantic like atom:category, it should be a MAY. If it is
inherently
At 10:02 PM -0400 4/26/05, Bob Wyman wrote:
Paul Hoffman wrote:
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.
Forgive me if I'm missing something obvious... While I
We chose not to put things like this in the Atom core. Feel free to
write an extension and discuss it here; there was certainly interest
in many directions about grappling with the many intertwined issues
that arise out of copyright, privacy, and so on.
--Paul Hoffman, Director
--Internet Mail
.
--Paul Hoffman, Director
--Internet Mail Consortium
it is finished. That
is a Very Good Thing for us, and for the people who will become new
implementers in the future when this mailing list is a historical
memory.
--Paul Hoffman, Director
--Internet Mail Consortium
.
Unless, of course, the WG decides we really do want to open it all up
again an take another probably four months of deciding what else we
want to add and change. We can do that by amending our charter. So
far, I have not heard consensus going towards that, but I could be
wrong.
--Paul Hoffman
. That means
that it is really, really likely that some implementers will write
and deploy code based on the draft that is going to the IESG, not
waiting to see if the IESG demands changes for the wire protocol or
the MUSTs and SHOULDs.
Do you really want that (he asks pejoratively)?
--Paul Hoffman
issues are cleared and when it is sent to the
RFC Editor. In retrospect, we could have done that for the IDN spec
as well. Does that work for you?
--Paul Hoffman, Director
--Internet Mail Consortium
.
--Paul Hoffman, Director
--Internet Mail Consortium
; I'm saying let's choose
our levels based on what we are supposed to be choosing from.
--Paul Hoffman, Director
--Internet Mail Consortium
1 - 100 of 137 matches
Mail list logo
