Sample -07 feed

[Tim Bray]

http://www.tbray.org/ongoing/ongoing.atom
Norm's RNC says it's OK.  -Tim

summary of editors' action items ...so far

[Robert Sayre]

Anything to add?
Julian Reschke wrote:
05-C05, 4.15.3 processing model Update -06: I'm still confused by the
text. For instance...
I agree that this section is gnarly. The editors will attempt to clarify
that section without making any normative changes, and will check with 
the WG to verify that no normative changes have been unintentionally 
introduced.

06-C01, 3.1.1 "type" Attribute thus *any* kind of change that
encourages "xhtml" would be appreciated.
While there is no consensus in favor of changing the document to 
'encourage' XHTML, more than one person has questioned the use of 
XHTML-Basic. I don't remember where this decision was made (Sam?). While 
I disagree that XHTML has a definite advantage over HTML, I am concerned 
that this choice will portray XHTML as somehow less capable, since the 
HTML section cites the more general HTML 4.01.

Graham wrote:
A quick bit of rewording would help. Currently it basically says "The
 type attribute may have the values..." three times with three
different rules. Changing it to "On the summary element, the type
atrribute may have the values..." stops the spec being apparently
self-contradicting.
The editors erred in failing to incorporate this suggestion in -07.
We'll get it this time.
Scott Hollenbeck wrote:
Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt
instead of RFC 2234 and confirm that everything that was valid before
is still valid.  The IESG approved this document as a Draft Standard
last week.
Will do.
Section 4: RFC 2045 is referenced.  2045 is on its way to being
obsoleted by draft-freed-mime-p4 (in the RFC Editor queue) and
draft-freed-media-type-reg (in last call).  Can the more recent
documents be referenced instead of 2045?
I think so. Will do.
Tim Bray wrote:
We do currently say that the schema is non-normative; having said
that, a statement that there is no DTD and no validity requirement
couldn't hurt.
Will add text to this effect.
Paul Hoffman wrote:

I'd really like to see some guidance in the document to describe
what the IESG should look for.  We're not atom experts, so it's
going to be hard to determine what we should and shouldn't approve.
Another paragraph will help future IESGs understand what they need
to consider when reviewing requests.

Sounds reasonable. (I was erring on the side of not micro-managing
the IESG.) Rob/Mark: please take a shot at some guidance for them.
Will do.
Scott Hollenbeck wrote w.r.t. the namespace:
Yes, we can do it this way.  Just please add some text so that so that IESG
reviewers understand that this is a known issue that we have a plan to
address.
OK, will do.
Robert Sayre

Re: strange Live Bookmark display of HTML version of draft in Firefox

[Phil Ringnalda]

Julian Reschke wrote:
Firefox ironically displays a "Live Bookmark" icon for 
 :-) 
https://bugzilla.mozilla.org/show_bug.cgi?id=257247
I've just had a hard time pushing for draconian autodiscovery, since 
it's vastly easier to find broken attempts at autodiscovery links which 
we would still like to subscribe to than it is to find non-feeds that 
trigger the current lax code.

Phil Ringnalda

Re: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07)

[Bill de hÓra]

Robert Sayre wrote:
Scott Hollenbeck wrote:
Thanks, but you didn't answer all of my question.  Has someone (you?)
confirmed that the schema and examples are consistent?  

OK, I'm probably not the best person to check the examples. Volunteers?
Me. Will be back to you in 24h.
cheers
Bill

updated issues list for draft 07

[Julian Reschke]

Hi,
I just updated my issues list based on the current draft (that is, I 
didn't yet have time to scan for potential new issues). Most of the 
issues are editorial, but two of them IMHO really need to be addressed 
before the draft can be submitted (05-C05 and 05-E12).

Also, the embedded RNC grammar now works for me with the standard Jing 
validator from James Clark's web site. Thanks!

Best regards, Julian
--
05-C05, 4.15.3 processing model

-06: 


"If the value of "type" ends with "+xml" or "/xml", the content of 
atom:content may include child elements, and SHOULD be suitable for 
handling by software that knows the indicated media type. If the "src" 
attribute is not provided, this would normally mean that the 
"atom:content" element would contain a single child element which would 
serve as the root element of the XML document of the indicated type."

The statement about the "src" attribute seems to be unnecessary given 
the SHOULD-level requirement to have local content (thus no "src" 
attribute).

"If the value of "type" begins with "text/" the content of atom:content 
MUST NOT contain child elements."

See 4.15.2: so is this a SHOULD or a MUST?
Update -06: I'm still confused by the text. For instance:
- is it intentional that 4.1.3.3 says ``If the value of "type" ends with 
"+xml" or "/xml"'', while 4.1.3.2 used ``If the value of type begins 
with "text/" or ends with "+xml"''?

- also, if content for +xml SHOULD be local (4.1.3.2), why does 4.1.3.3. 
point 4, make statements about situations where it comes with @src 
attribute? Maybe it's not a SHOULD requirement after all?

05-E02, Notational Conventions

I think this should come with the following URL: 


Update -06: I think it would be good if all W3C references came with URLs.

05-E05, 3.2.2 atom:uri
"The content of atom:uri in a Person construct MUST be a URI reference 
[RFC2396bis]."
06: 


Directly point to RFC3986's section (here: 4.1).
Update -06: I still think that spelling out the section number will make 
it easier to actually locate the definition.

05-E06, 3.2.3 atom:email
http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.3
"Its content MUST be an e-mail address [RFC2822]."
Again, please refer directly to the definition. In this case, it seems 
to be section 3.4.1 (addr-spec production).

05-E08, 4.6.2 rel attribute

06: 


"...same name registered within the IANA Registry of Link Relations 
Section 9, and..."

Put the section reference into brackets.
05-E12, 11 references

06: 


Here's a producedural question: if we have normative references to the 
protocol and the feed discovery document, the spec won't get published 
until those are done, too. Is everybody aware of that?

Update -06: we still have a normative reference to the feed discovery 
spec, which, according to , has 
expired. If this reference is expected to stay in, we'll have to 
actually finish that spec as well :-)

06-C01, 3.1.1 "type" Attribute

This has been mentioned before...: as far as I can tell, it's far easier 
for recipients to process "xhtml" compared to "html" (no tag-soup parser 
needed), thus *any* kind of change that encourages "xhtml" would be 
appreciated.

Update -07: I acknowledge that the WG is unable/unwilling to look at 
this topic again after att the discussions we had about it earlier in. 
I'll leave it here inside my issues list anyway so that my disagreement 
is at least recorded :-)

RE: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Scott Hollenbeck]

> Correct. I was assuming that, once everything else got approved, you 
> would put a DISCUSS vote on the document because of the lack of final 
> namespace. We then ask the W3C for it, get it, tell you, and make the 
> change to the n+1 version of the document (along with the editorial 
> comments that often come out of an IESG review). Does that sound 
> doable?

Yes, we can do it this way.  Just please add some text so that so that IESG
reviewers understand that this is a known issue that we have a plan to
address.

-Scott-

RE: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Paul Hoffman]

At 2:25 PM -0400 4/5/05, Scott Hollenbeck wrote:
As described in 2434, "IESG Approval", "though the IESG has discretion to
request documents or other supporting materials on a case-by-case basis".
Right.
I'd really like to see some guidance in the document to describe what the
IESG should look for.  We're not atom experts, so it's going to be hard to
determine what we should and shouldn't approve.  Another paragraph will help
future IESGs understand what they need to consider when reviewing requests.
Sounds reasonable. (I was erring on the side of not micro-managing 
the IESG.) Rob/Mark: please take a shot at some guidance for them.


 At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote:
 >There needs to be both text explaining why IETF practice
 isn't being used
 Good.
 >and there needs to be an identified URI.
 Bad.
 >   We don't need the URI *right now*,
 >but I want it in the document BEFORE I bring the document to
 the IESG for
 >review.  Explanatory text will suffice for last call purposes.
 Just to be clear: you are asking us to get the final URI for the
 namespace *before* the IESG has approved of the document. 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)?
Hmm.  Part of the problem is that there is no "normal" editing opportunity
once the document is in the hands of the IESG.  The editors can make changes
as a result of IESG review, or in auth48, but those changes are supposed to
be directed.  Auth48 changes are supposed to be editorial only.  This is
clearly a normative situation.
Correct. I was assuming that, once everything else got approved, you 
would put a DISCUSS vote on the document because of the lack of final 
namespace. We then ask the W3C for it, get it, tell you, and make the 
change to the n+1 version of the document (along with the editorial 
comments that often come out of an IESG review). Does that sound 
doable?

The other part of the problem is that you're asking the IESG to review a
specification that is incomplete without that little detail, and what's in
there now looks very obviously non-standard.  If you want to pursue a course
of action that is similar to what was done with the IDN prefix [1] you're
going to have to be a bit more clear about why the spec is incomplete.
I'm fine with that. And, yes, I was modelling this process after than one.
  I'm
OK with that, but please add text to the document to explain what needs to
be done, who will do it, and when it needs to be done.  Include a note that
says "this paragraph to be removed by the RFC Editor" if appropriate.  If
this all means that the URI will be provided to the RFC Editor when they ask
for it to finish the document, fine -- just say so.
My preference is that the namespace be minted and included between 
the time that all other 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

RE: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Scott Hollenbeck]

> -Original Message-
> From: Paul Hoffman [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 05, 2005 2:07 PM
> To: Tim Bray; Scott Hollenbeck
> Cc: atom-syntax@imc.org
> Subject: Re: AD Review Comments and Questions: 
> draft-ietf-atompub-format-07
> 
> 
> At 9:26 AM -0700 4/5/05, Tim Bray wrote:
> >>Section 7.1: what process is the IESG supposed to use to 
> review registration
> >>requests?  Please see section 2 of RFC 2434/BCP 26 for 
> mechanisms that might
> >>be used and please specify one in the document.
> >
> >Paul, care to take the lead on this?  -Tim
> 
> Nope. Scott: can you be more specific about your question? Section 
> 7.1 seems pretty clear to me, but I'm possibly missing something.

As described in 2434, "IESG Approval", "though the IESG has discretion to
request documents or other supporting materials on a case-by-case basis".
I'd really like to see some guidance in the document to describe what the
IESG should look for.  We're not atom experts, so it's going to be hard to
determine what we should and shouldn't approve.  Another paragraph will help
future IESGs understand what they need to consider when reviewing requests.

> At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote:
> >There needs to be both text explaining why IETF practice 
> isn't being used
> 
> Good.
> 
> >and there needs to be an identified URI.
> 
> Bad.
> 
> >   We don't need the URI *right now*,
> >but I want it in the document BEFORE I bring the document to 
> the IESG for
> >review.  Explanatory text will suffice for last call purposes.
> 
> Just to be clear: you are asking us to get the final URI for the 
> namespace *before* the IESG has approved of the document. 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)?

Hmm.  Part of the problem is that there is no "normal" editing opportunity
once the document is in the hands of the IESG.  The editors can make changes
as a result of IESG review, or in auth48, but those changes are supposed to
be directed.  Auth48 changes are supposed to be editorial only.  This is
clearly a normative situation.

The other part of the problem is that you're asking the IESG to review a
specification that is incomplete without that little detail, and what's in
there now looks very obviously non-standard.  If you want to pursue a course
of action that is similar to what was done with the IDN prefix [1] you're
going to have to be a bit more clear about why the spec is incomplete.  I'm
OK with that, but please add text to the document to explain what needs to
be done, who will do it, and when it needs to be done.  Include a note that
says "this paragraph to be removed by the RFC Editor" if appropriate.  If
this all means that the URI will be provided to the RFC Editor when they ask
for it to finish the document, fine -- just say so.

-Scott-

[1]
I'll let Paul explain this reference if anyone asks.

Re: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Paul Hoffman]

At 9:26 AM -0700 4/5/05, Tim Bray wrote:
Section 7.1: what process is the IESG supposed to use to review registration
requests?  Please see section 2 of RFC 2434/BCP 26 for mechanisms that might
be used and please specify one in the document.
Paul, care to take the lead on this?  -Tim
Nope. Scott: can you be more specific about your question? Section 
7.1 seems pretty clear to me, but I'm possibly missing something.

At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote:
There needs to be both text explaining why IETF practice isn't being used
Good.
and there needs to be an identified URI.
Bad.
  We don't need the URI *right now*,
but I want it in the document BEFORE I bring the document to the IESG for
review.  Explanatory text will suffice for last call purposes.
Just to be clear: you are asking us to get the final URI for the 
namespace *before* the IESG has approved of the document. 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, Director
--Internet Mail Consortium

strange Live Bookmark display of HTML version of draft in Firefox

[Julian Reschke]

Hi,
Firefox ironically displays a "Live Bookmark" icon for 
 :-) 
This is caused by LINK tags such as

  
...whenever a title contains the string "Atom", it is mis-detected as a 
feed link. Guess we'll need to finish the feed discovery description and 
send it over to the Mozilla developers...

Best regards, Julian

Re: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07)

[Robert Sayre]

Scott Hollenbeck wrote:
Thanks, but you didn't answer all of my question.  Has someone (you?)
confirmed that the schema and examples are consistent?  
OK, I'm probably not the best person to check the examples. Volunteers?
Robert Sayre

RE: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Scott Hollenbeck]

> -Original Message-
> From: Tim Bray [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 05, 2005 12:26 PM
> To: Scott Hollenbeck
> Cc: atom-syntax@imc.org
> Subject: Re: AD Review Comments and Questions: 
> draft-ietf-atompub-format-07
> 
> 
> On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote:

[snip]

> > Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice 
> for naming 
> > XML
> > namespaces.  Why are namespace URIs (such as http://purl.org) that 
> > don't
> > conform to this practice being used?
> 
> Our plan, as we discussed with you & Ted. last year, is to use a W3C 
> namespace.  The current value is a placeholder.  Should we 
> note this in 
> -08?

There needs to be both text explaining why IETF practice isn't being used
and there needs to be an identified URI.  We don't need the URI *right now*,
but I want it in the document BEFORE I bring the document to the IESG for
review.  Explanatory text will suffice for last call purposes.

[snip]

> > The MIME media type registration template included in 
> section 7 MUST be
> > submitted to the ietf-types list ([EMAIL PROTECTED]) for 
> > review.  A
> > two-week review period is standard for requests to register 
> new types 
> > in the
> > standards tree.  Please see the list archives [1] for 
> samples if help 
> > is
> > needed in crafting a review request and please send the 
> request ASAP.
> 
> Scott, what's the scheduling on that?  Do we launch that right now, 
> independent of the rest of the document review process?

Start it now.  It can run concurrent with or before the last call.  If you
wait until after the last call starts it becomes the gating factor to having
the document ready for IESG review.

-Scott-

RE: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07)

[Scott Hollenbeck]

Robert,

Thanks, but you didn't answer all of my question.  Has someone (you?)
confirmed that the schema and examples are consistent?  I really don't have
the time to double-check something that the working group should have done
itself if that means installing and getting familiar with a new software
package.

I saw your follow-up; thanks.

-Scott-

> -Original Message-
> From: Robert Sayre [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 05, 2005 12:05 PM
> To: Scott Hollenbeck
> Cc: atom-syntax@imc.org
> Subject: RNG and examples (was: AD Review Comments and 
> Questions: draft-ietf-atompub-format-07)
> 
> 
> Scott Hollenbeck wrote:
> 
> > The document includes an informative RELAX NG schema and 
> several examples.
> > What has been done to confirm that the schema is free of 
> errors and that all
> > of the examples given in the document are valid according 
> to the schema?  (I
> > could check an XML Schema myself, but I don't have the 
> tools I need to check
> > RELAX NG.)
> 
> The draft is generated from an RFC2629 XML file which 
> contains no schema 
> fragments or examples. The schema fragments are generated 
> from the full 
> schema. To create the text version, the schema, fragments, 
> and examples 
> are inserted in a SAX pipeline, and xml2rfc.tcl generates the 
> draft from 
> the resulting document. Since the schema and examples are stored in 
> separate files, it's easy to check them with a command-line 
> validator. I 
> use James Clark's Jing[0].
> 
> Robert Sayre
> 
> [0] http://www.thaiopensource.com/relaxng/jing.html
> 

Re: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Bjoern Hoehrmann]

* Tim Bray wrote:
>Our plan, as we discussed with you & Ted. last year, is to use a W3C 
>namespace.  The current value is a placeholder.  Should we note this in 
>-08?

Do you have a pointer to this?

>> [draft-freed-media-type-reg]
>
>Rob/Mark?

(Note that this is also a matter of reviewing the draft
and checking that we took all differences into account).

>> The MIME media type registration template included in section 7 MUST be
>> submitted to the ietf-types list ([EMAIL PROTECTED]) for 
>> review.

>Scott, what's the scheduling on that?  Do we launch that right now, 
>independent of the rest of the document review process?

We should announce this to [EMAIL PROTECTED] aswell.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: AD Review Comments and Questions: draft-ietf-atompub-format-07

[Tim Bray]

On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote:
I intend to ask the XML Directorate to review the document during the 
last
call period.  Anything they find can be dealt with along with any 
other last
call comments.
For the WG's info: The Directorate is a volunteer group of alleged "XML 
experts" that reviews I-D's that use XML; I'm one of them, BTW.

The document includes an informative RELAX NG schema and several 
examples.
What has been done to confirm that the schema is free of errors and 
that all
of the examples given in the document are valid according to the 
schema?  (I
could check an XML Schema myself, but I don't have the tools I need to 
check
RELAX NG.)
Norm/Rob/Mark?
Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice for naming 
XML
namespaces.  Why are namespace URIs (such as http://purl.org) that 
don't
conform to this practice being used?
Our plan, as we discussed with you & Ted. last year, is to use a W3C 
namespace.  The current value is a placeholder.  Should we note this in 
-08?

Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt 
instead
of RFC 2234 and confirm that everything that was valid before is still
valid.  The IESG approved this document as a Draft Standard last week.
Rob/Mark?
Section 2 describes a requirement for well-formedness, but it doesn't
mention validity.  I suspect that validity isn't a requirement given 
that
the RELAX NG schema is informative, but it would be better if a 
specific
statement were included to note that validity is not a requirement.
Hmm, I would say that validity isn't a requirement because the 
syntactic constraints are (we think) fully given in the text.  The 
group consciously decided not to make the schema normative, for that 
reason.  We do currently say that the schema is non-normative; having 
said that, a statement that there is no DTD and no validity requirement 
couldn't hurt.  Rob/Mark?

Section 4: RFC 2045 is referenced.  2045 is on its way to being 
obsoleted by
draft-freed-mime-p4 (in the RFC Editor queue) and 
draft-freed-media-type-reg
(in last call).  Can the more recent documents be referenced instead of
2045?
Rob/Mark?
The MIME media type registration template included in section 7 MUST be
submitted to the ietf-types list ([EMAIL PROTECTED]) for 
review.  A
two-week review period is standard for requests to register new types 
in the
standards tree.  Please see the list archives [1] for samples if help 
is
needed in crafting a review request and please send the request ASAP.
Scott, what's the scheduling on that?  Do we launch that right now, 
independent of the rest of the document review process?

Section 7.1: what process is the IESG supposed to use to review 
registration
requests?  Please see section 2 of RFC 2434/BCP 26 for mechanisms that 
might
be used and please specify one in the document.
Paul, care to take the lead on this?  -Tim

Re: RNG and examples

[Robert Sayre]

Robert Sayre wrote:
Scott Hollenbeck wrote:
that all
of the examples given in the document are valid according to the 
schema? 
Oh, you said *all*. The document fragments haven't been automatically 
checked, and I just spotted one mistake. The link element in 4.2.9.2 is 
broken.

I'm not sure what we can do to ensure the small document fragments are 
valid, other than read them closely.

Robert Sayre

RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07)

[Robert Sayre]

Scott Hollenbeck wrote:
The document includes an informative RELAX NG schema and several examples.
What has been done to confirm that the schema is free of errors and that all
of the examples given in the document are valid according to the schema?  (I
could check an XML Schema myself, but I don't have the tools I need to check
RELAX NG.)
The draft is generated from an RFC2629 XML file which contains no schema 
fragments or examples. The schema fragments are generated from the full 
schema. To create the text version, the schema, fragments, and examples 
are inserted in a SAX pipeline, and xml2rfc.tcl generates the draft from 
the resulting document. Since the schema and examples are stored in 
separate files, it's easy to check them with a command-line validator. I 
use James Clark's Jing[0].

Robert Sayre
[0] http://www.thaiopensource.com/relaxng/jing.html

AD Review Comments and Questions: draft-ietf-atompub-format-07

[Scott Hollenbeck]

Your working group chairs have asked me to shepherd
draft-ietf-atompub-format-07 through IETF last call.  As part of that
process, I have an obligation to review the document myself.  I've completed
my review and I'd like to share my comments and a few questions with the
group.

A new version of the document is probably needed before I can submit the
last call request.  I don't think I found any major problems, but I'd prefer
to close known issues before asking the community for input -- especially
since this working group has never met at a face-to-face IETF meeting.

I intend to ask the XML Directorate to review the document during the last
call period.  Anything they find can be dealt with along with any other last
call comments.

Comments/Questions:

The document includes an informative RELAX NG schema and several examples.
What has been done to confirm that the schema is free of errors and that all
of the examples given in the document are valid according to the schema?  (I
could check an XML Schema myself, but I don't have the tools I need to check
RELAX NG.)

Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice for naming XML
namespaces.  Why are namespace URIs (such as http://purl.org) that don't
conform to this practice being used?

Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt instead
of RFC 2234 and confirm that everything that was valid before is still
valid.  The IESG approved this document as a Draft Standard last week.

Section 2 describes a requirement for well-formedness, but it doesn't
mention validity.  I suspect that validity isn't a requirement given that
the RELAX NG schema is informative, but it would be better if a specific
statement were included to note that validity is not a requirement.

Section 4: RFC 2045 is referenced.  2045 is on its way to being obsoleted by
draft-freed-mime-p4 (in the RFC Editor queue) and draft-freed-media-type-reg
(in last call).  Can the more recent documents be referenced instead of
2045?

The MIME media type registration template included in section 7 MUST be
submitted to the ietf-types list ([EMAIL PROTECTED]) for review.  A
two-week review period is standard for requests to register new types in the
standards tree.  Please see the list archives [1] for samples if help is
needed in crafting a review request and please send the request ASAP.

Section 7.1: what process is the IESG supposed to use to review registration
requests?  Please see section 2 of RFC 2434/BCP 26 for mechanisms that might
be used and please specify one in the document.

-Scott-

[1]
http://eikenes.alvestrand.no/pipermail/ietf-types/

Re: PaceFeedIdOrSelf

[Martin Duerst]

+1
At 02:59 05/04/05, Antone Roundy wrote:
>
>http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf 

Fwd: PaceFeedIdOrSelf

[Janne Jalkanen]

This 23()=(#"=)( GMail, I always send to the author instead of the
list...  Sorry, Julian.

-- Forwarded message --
From: Janne Jalkanen <[EMAIL PROTECTED]>
Date: Apr 5, 2005 12:31 PM
Subject: Re: PaceFeedIdOrSelf
To: Julian Reschke <[EMAIL PROTECTED]>


+1.

Also, a second question on enclosures: if you have a  in your , I read it that you MUST also have a
, if there is no -element?  So putting
plain enclosures requires also some content...

Necessary?  Yes?  No?

/Janne