and comment freely. We're getting close to being
finished, which is of course the over-arching goal.
--Paul Hoffman, Director
--Internet Mail Consortium
At 9:12 AM +0100 1/25/05, Julian Reschke wrote:
Aren't you planning to do a working-group last call before that?
We're planning to ask for editorial changes after the next draft.
Those are also welcome now on the current draft.
--Paul Hoffman, Director
--Internet Mail Consortium
into
covering everything.
--Paul Hoffman, Director
--Internet Mail Consortium
Identity Constructs...
--Paul Hoffman, Director
--Internet Mail Consortium
.
This contrasts with RSS 2.0 where guid is by default a permalink,
and RSS 1.0 where rdf:about is required to be the same as rss:link.
...and that is a *very* good reason to include it in the document.
--Paul Hoffman, Director
--Internet Mail Consortium
be considered different identifiers, because URI %-escaping
is significant for the purposes of comparison.
That covers my concerns quite well. +1
--Paul Hoffman, Director
--Internet Mail Consortium
feel free to continue talking
about the current Paces now, and to continue to suggest editorial
changes to the current Internet Draft.
--Paul Hoffman, Director
--Internet Mail Consortium
At 9:57 PM -0500 2/2/05, Robert Sayre wrote:
Paul Hoffman wrote:
Please do *not* rush out to write a Pace unless it is for something
that is *truly* part of the Atom core, and you really believe that
it is likely that there will be consensus within a week.
Sorry, this is not a legitimate
not in a way that will be confusing to people who only care about
entries and normal feeds. That's what extensions are for.
--Paul Hoffman, Director
--Internet Mail Consortium
of all entries ever published in any feed, you need to say that
explicitly.
I'm with Mnot on this one.
So am I; I should have sad ...in any two different entries, ever.
And an archive of a feed can have the entry many times, no problem.
--Paul Hoffman, Director
--Internet Mail Consortium
-1. IETF documents have to have a Security Considerations section
that describes general security issues. In no cases that I know of do
they contain protocol specification. See RFC 3552 for more info.
--Paul Hoffman, Director
--Internet Mail Consortium
remember to have useful Subject: lines, OK? If a thread
changes direction, please change the subject line. Thanks!
--Paul Hoffman, Director
--Internet Mail Consortium
-1. Not core. The current text has a simple way of creating archives,
and extensions can be used to create more specialized archive formats.
--Paul Hoffman, Director
--Internet Mail Consortium
At 5:09 PM + 2/7/05, Bill de hÓra wrote:
Paul Hoffman wrote:
-1. IETF documents have to have a Security Considerations section
that describes general security issues. In no cases that I know of
do they contain protocol specification. See RFC 3552 for more info.
Is that -1 to the proposed
+1. It is a simple clarification that shows the intention without
restricting anyone.
--Paul Hoffman, Director
--Internet Mail Consortium
Someone pointed out that some of the Paces in the current rotation
have been informally withdrawn by their authors. Good point. If you
have such a Pace, please send mail to the list saying so, and Sam can
remove it from the wiki.
--Paul Hoffman, Director
--Internet Mail Consortium
At 1:17 PM -0500 2/7/05, Robert Sayre wrote:
+1. Says all that we need to without getting into HTML too deeply.
Wearing my IETF hat, +1. Also, be aware that there is probably a 50%
chance that we will get additions to this section from the IETF last
call or from the IESG.
--Paul Hoffman
-1. If the current security documents that cover the material are
insufficient, they should be fixed, and not have it listed in our
document. We should only point to where generic information can be
found and list things that are Atom-specific.
--Paul Hoffman, Director
--Internet Mail
.
I'm very confused. Clients that show the entries of those feeds in
the received order are perfectly acceptable according to the wording
of this Pace.
--Paul Hoffman, Director
--Internet Mail Consortium
-1 because it is incomplete (no text for the new profiles in Section
6). The specification of those profiles could have a major technical
effect on the rest of the document.
--Paul Hoffman, Director
--Internet Mail Consortium
-1 because it doesn't feel like it belongs in the core. That is, when
more developers have real profiles that they want to differentiate
from the atom core, adding a @profile attribute seems like a good
extension.
--Paul Hoffman, Director
--Internet Mail Consortium
, the pitchforks will be drawn.
--Paul Hoffman, Director
--Internet Mail Consortium
a way to have others check our regex.
Some IETF apps folks who haven't looked at this document will do so
during IETF Last Call, and those folks can chew regexs in their sleep.
--Paul Hoffman, Director
--Internet Mail Consortium
not in the business of saying this
newer one is better.
--Paul Hoffman, Director
--Internet Mail Consortium
for XHTML that could cause them to create text that will
be rejected as badly formed. In other words, HTML is just easier.
--Paul Hoffman, Director
--Internet Mail Consortium
, no.
--Paul Hoffman, Director
--Internet Mail Consortium
round of the format
draft. There are clearly still feelings about some of the closed
Paces. However, having that discussion while the draft is in flux
doesn't help anyone. I suggest that those discussions abate until the
next draft comes out and we see all of the changes in a single place.
--Paul
can still offer editorial
suggestions. This is also a reasonable time to start creating format
extensions and talking about them here.
--Paul Hoffman, Director
--Internet Mail Consortium
it to. This kind of does the model say A
or B discussion is quite appropriate in IETF last call, where folks
who have very different model ideas might join in.
--Paul Hoffman, Director
--Internet Mail Consortium
to make the current edits available for review
(*before* it is committed after the end of the IETF meeting)?
Your assumption is completely wrong. The WG will review the next
draft before passing on to the IETF. The timing of the IETF meeting
is completely inconsequential.
--Paul Hoffman
this as an individual, as others have suggested.
--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
. 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
.
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
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
.
--Paul Hoffman, Director
--Internet Mail Consortium
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
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
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
traffic in the past week.
--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
-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
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
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
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
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
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
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
. 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
.../
/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
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
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
signed feeds and entries should do.
--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
-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
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
://www.intertwingly.net/wiki/pie/FrontPage).
--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
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
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 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
properly.
--Paul Hoffman, Director
--Internet Mail Consortium
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
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
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
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 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
feature/behaviour but it seems
something like a flag that you have to give.
Agree.
--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
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
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
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
1 - 100 of 137 matches
Mail list logo
