Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)

[Thomas Broyer]

2006/11/29, James M Snell:


The problem I have with the WHAT-WG definition of the alternate and feed
relations is the unintended conflict that occurs when the alternate
representation of a page happens to be an Atom Entry Document.

The HTML5 draft says,

"If the alternate keyword is used with the type attribute set to
the value application/rss+xml or the value application/atom+xml,
then the user agent must treat the link as it would if it had
the feed keyword specified as well."

It goes on to say,

"The feed keyword indicates that the referenced document is a
syndication feed. If the alternate link type is also specified,
then the feed is specifically the feed for the current document"

The problem with this is that the "application/atom+xml" media type is
also used for Atom Entry Documents:

  

The current WHAT-WG definition is inadequate.


Already exposed here:
http://www.imc.org/atom-syntax/mail-archive/msg19100.html
and there:
http://www.imc.org/atom-syntax/mail-archive/msg19107.html
;-)


There are three possible solutions:

  1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom
 media type is addressed


+1 (see above; see also Mark Baker's mail in this same thread –not yet
in the archives)


  2. We add a type parameter to the application/atom+xml media type
 to differentiate feed and entry documents,
 e.g. application/atom+xml;type=feed,
  application/atom+xml;type=entry


+1


 When the media type is used without the type parameter,
 type=feed is assumed.


I'd rather say: if there's no 'type' parameter, assume nothing, it can
be a feed or entry; this would make the "updated media-type" fully
backwards compatible with the current one (which shipped a year ago).


  3. We define a new media type for Atom Entry Documents,
 e.g. application/atomentry+xml


-1

--
Thomas Broyer

RE: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)

[Tse Shing Chi \(Franklin/Whale\)]

I would like to have application/atomentry+xml for entry. As a result, 
application/atom+xml must be a feed.

>   2. We add a type parameter to the application/atom+xml media type
>  to differentiate feed and entry documents,
>  e.g. application/atom+xml;type=feed,
>   application/atom+xml;type=entry
>
>  When the media type is used without the type parameter,
>  type=feed is assumed.

This cause is ok, but a bit complicated. We have already had a charset 
parameter. If using both the type and the charset parameters together, then the 
Content-Type header will be application/atom+xml; type=feed; charset=utf-8. If 
type parameter is not declared, then type=feed is assumed because most feeds 
are serving with application/atom+xml with or without the charset parameter 
today.

Franklin Tse


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Broyer
Sent: Wednesday, November 29, 2006 16:04
To: Atom-Syntax
Subject: Re: WHAT-WG, feed and alternate (was: Re: 
PaceAutoDiscoveryDraftIsPointless)


2006/11/29, James M Snell:
>
> The problem I have with the WHAT-WG definition of the alternate and feed
> relations is the unintended conflict that occurs when the alternate
> representation of a page happens to be an Atom Entry Document.
>
> The HTML5 draft says,
>
> "If the alternate keyword is used with the type attribute set to
> the value application/rss+xml or the value application/atom+xml,
> then the user agent must treat the link as it would if it had
> the feed keyword specified as well."
>
> It goes on to say,
>
> "The feed keyword indicates that the referenced document is a
> syndication feed. If the alternate link type is also specified,
> then the feed is specifically the feed for the current document"
>
> The problem with this is that the "application/atom+xml" media type is
> also used for Atom Entry Documents:
>
>   
>
> The current WHAT-WG definition is inadequate.

Already exposed here:
http://www.imc.org/atom-syntax/mail-archive/msg19100.html
and there:
http://www.imc.org/atom-syntax/mail-archive/msg19107.html
;-)

> There are three possible solutions:
>
>   1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom
>  media type is addressed

+1 (see above; see also Mark Baker's mail in this same thread –not yet
in the archives)

>   2. We add a type parameter to the application/atom+xml media type
>  to differentiate feed and entry documents,
>  e.g. application/atom+xml;type=feed,
>   application/atom+xml;type=entry

+1

>  When the media type is used without the type parameter,
>  type=feed is assumed.

I'd rather say: if there's no 'type' parameter, assume nothing, it can
be a feed or entry; this would make the "updated media-type" fully
backwards compatible with the current one (which shipped a year ago).

>   3. We define a new media type for Atom Entry Documents,
>  e.g. application/atomentry+xml

-1

-- 
Thomas Broyer

PaceEntryMediatype

[James M Snell]

http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

#pragma section-numbers off

== Abstract ==

For the current Atom Publishing Protocol draft...

Create a new media type for Atom Entry Documents: application/atomentry+xml

Deprecate the use of application/atom+xml for Entry Documents.

== Status ==

Proposed

== Rationale ==

The fact that one media type is used for both Feed and Entry documents
has repeatedly come up as a problem on more than one occasion.  We have
an opportunity to fix this problem now.

== Proposal ==

Add to Section 6.1

{{{
Atom Entry Documents are identified with the "application/atomentry+xml"
media type (See section 15).
}}}

Renumber existing section 15.3 to 15.4

Insert..

{{{
15.3 Content-type registration for 'application/atomentry+xml'

   MIME media type name:  application
   MIME subtype name:  atomentry+xml
   Mandatory parameters:  None.
   Optional parameters:
  "charset":  This parameter has semantics identical to the charset
 parameter of the "application/xml" media type as specified in
 [RFC3023].
   Encoding considerations:  Identical to those of "application/xml" as
  described in [RFC3023], Section 3.2.
   Security considerations:  As defined in this specification.
  In addition, as this media type uses the "+xml" convention, it
  shares the same security considerations as described in [RFC3023],
  Section 10.
   Interoperability considerations:  RFC 4287 registers the
  application/atom+xml Content-Type for both Atom Feed and Entry
  Documents.  For Atom Entry Documents, the use of the
  application/atom+xml type should be avoided.
   Published specification:  This specification.
   Applications that use this media type:  No known applications
  currently use this media type.

   Additional information:

   Magic number(s):  As specified for "application/xml" in [RFC3023],
  Section 3.2.
   File extension:  .atomentry
   Fragment identifiers:  As specified for "application/xml" in
  [RFC3023], Section 5.
   Base URI:  As specified in [RFC3023], Section 6.
   Macintosh File Type code:  TEXT
   Person and email address to contact for further information:
 This specification's author(s)
   Intended usage:  COMMON
   Author/Change controller:  IESG
}}}

== Impacts ==


== Notes ==



CategoryProposals

Re: PaceEntryMediatype

[Jan Algermissen]

On Nov 29, 2006, at 5:16 PM, James M Snell wrote:




Create a new media type for Atom Entry Documents: application/ 
atomentry+xml


Deprecate the use of application/atom+xml for Entry Documents.


That is a *very* good idea!!

+1

Jan






== Status ==

Proposed

== Rationale ==

The fact that one media type is used for both Feed and Entry documents
has repeatedly come up as a problem on more than one occasion.  We  
have

an opportunity to fix this problem now.

== Proposal ==

Add to Section 6.1

{{{
Atom Entry Documents are identified with the "application/atomentry 
+xml"

media type (See section 15).
}}}

Renumber existing section 15.3 to 15.4

Insert..

{{{
15.3 Content-type registration for 'application/atomentry+xml'

   MIME media type name:  application
   MIME subtype name:  atomentry+xml
   Mandatory parameters:  None.
   Optional parameters:
  "charset":  This parameter has semantics identical to the  
charset

 parameter of the "application/xml" media type as specified in
 [RFC3023].
   Encoding considerations:  Identical to those of "application/ 
xml" as

  described in [RFC3023], Section 3.2.
   Security considerations:  As defined in this specification.
  In addition, as this media type uses the "+xml" convention, it
  shares the same security considerations as described in  
[RFC3023],

  Section 10.
   Interoperability considerations:  RFC 4287 registers the
  application/atom+xml Content-Type for both Atom Feed and Entry
  Documents.  For Atom Entry Documents, the use of the
  application/atom+xml type should be avoided.
   Published specification:  This specification.
   Applications that use this media type:  No known applications
  currently use this media type.

   Additional information:

   Magic number(s):  As specified for "application/xml" in [RFC3023],
  Section 3.2.
   File extension:  .atomentry
   Fragment identifiers:  As specified for "application/xml" in
  [RFC3023], Section 5.
   Base URI:  As specified in [RFC3023], Section 6.
   Macintosh File Type code:  TEXT
   Person and email address to contact for further information:
 This specification's author(s)
   Intended usage:  COMMON
   Author/Change controller:  IESG
}}}

== Impacts ==


== Notes ==



CategoryProposals

Re: PaceEntryMediatype

[Mark Baker]

-1

- there's nothing special about an entry document
- AFAICT (because they're not referenced from the pace), the problems
referred to have other causes.  I prefer we fix those instead.

Mark.

Re: PaceEntryMediatype

[Jan Algermissen]

Hi Mark,

would you suggest to put service and categories into application/atom+xml as 
well?

Hmm, ah, I think I see what you mean: When a peer declares it understands 
application/atom+xml the understanding of  is mandatory anyhow. Despite 
the additional inspection into the documents root element feed and entry belong 
into the same family you cannot have one without the other therefore the media 
type should not be split.

Is that what you think?


Jan



On Wednesday, November 29, 2006, at 06:56PM, "Mark Baker" <[EMAIL PROTECTED]> 
wrote:
>
>-1
>
>- there's nothing special about an entry document
>- AFAICT (because they're not referenced from the pace), the problems
>referred to have other causes.  I prefer we fix those instead.
>
>Mark.
>
>
>

Re: PaceEntryMediatype

[James M Snell]

One such problem occurs in atom:link and atom:content elements.
Specifically:

  
  

Given no other information I have no way of knowing whether these are
references to Feed or Entry documents.

- James

Mark Baker wrote:
> -1
> 
> - there's nothing special about an entry document
> - AFAICT (because they're not referenced from the pace), the problems
> referred to have other causes.  I prefer we fix those instead.
> 
> Mark.
> 

Re: PaceEntryMediatype

[James M Snell]

I'm fine either way. Wouldn't take that long for me to write up a draft.

- James

Tim Bray wrote:
> On Nov 29, 2006, at 8:16 AM, James M Snell wrote:
> 
>> http://www.intertwingly.net/wiki/pie/PaceEntryMediatype
>>
>> #pragma section-numbers off
>>
>> == Abstract ==
>>
>> For the current Atom Publishing Protocol draft...
> 
> Irrespective of the merits of the new media type, the APP spec seems
> like the wrong place to define it.  Since nobody wants to obsolete 4287,
> why not a short clean standalone I-D?  -Tim
> 
> 

Re: PaceEntryMediatype

[Henry Story]

There are all kinds of other things you don't know: like what's  
inside the document, if the server is up, what the title is, ... What  
interoperability problem is solved by having a new mime type? And  
would that not be solvable by




Not that I really care that much.

Henry

On 29 Nov 2006, at 10:22, James M Snell wrote:



One such problem occurs in atom:link and atom:content elements.
Specifically:

  
  

Given no other information I have no way of knowing whether these are
references to Feed or Entry documents.

- James

Mark Baker wrote:

-1

- there's nothing special about an entry document
- AFAICT (because they're not referenced from the pace), the problems
referred to have other causes.  I prefer we fix those instead.

Mark.

Re: PaceEntryMediatype

[Tim Bray]

On Nov 29, 2006, at 8:16 AM, James M Snell wrote:


http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

#pragma section-numbers off

== Abstract ==

For the current Atom Publishing Protocol draft...


Irrespective of the merits of the new media type, the APP spec seems  
like the wrong place to define it.  Since nobody wants to obsolete  
4287, why not a short clean standalone I-D?  -Tim

Re: PaceEntryMediatype

[Mark Baker]

On 11/29/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:

Hi Mark,

would you suggest to put service and categories into application/atom+xml as 
well?


I haven't paid much attention to those, but AFAICT they have different
processing models (e.g. extensibility rules) and so IMO, comprise
different document formats.  Separate media types are fine.


Hmm, ah, I think I see what you mean: When a peer declares it understands 
application/atom+xml the understanding of  is mandatory anyhow. Despite 
the additional inspection into the documents root element feed and entry belong into 
the same family you cannot have one without the other therefore the media type should 
not be split.

Is that what you think?


Yes, but more than that.  An entry document is, AFAICT, little more
than shorthand for a feed with one entry, minus the feed-specific
metadata.  It's processing is a subset of feed processing.  If the
processing or content model of entry is extended, it applies to both
feed documents and entry documents.

And +1 to what Henry just said in response to James.  It's also not a
huge deal to me.  But I've just raised the rel="feed" inference issue
with the WHAT WG, so we'll see how that goes; if resolved to my
liking, then there's one less reason for a new media type.

Mark.

Re: PaceEntryMediatype

[Bill de hOra]

James M Snell wrote:


Create a new media type for Atom Entry Documents: application/atomentry+xml


+0

cheers
Bill

Re: PaceEntryMediatype

[Thomas Broyer]

2006/11/29, James M Snell:

Create a new media type for Atom Entry Documents: application/atomentry+xml

Deprecate the use of application/atom+xml for Entry Documents.


I'd largely prefer augmenting the existing media type with a 'type' parameter:
- application/atom+xml => either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed => feed
- application/atom+xml;type=entry => entry


{{{
Atom Entry Documents are identified with the
 "application/atomentry+xml" media type (See section 15).
}}}


How about defining a "tree" similar to the */vnd.* one?
- application/atom+xml => feed or entry document
- application/atom.categories+xml => category document
- application/atom.service+xml => service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml => entry document


As for Tim's concerns, I'd also prefer having it done outside the APP.

Also, the APP draft would need to be updated to remove the "entry"
special value for app:accept, as it would be equivalent to the new or
revised media type (app:accept=application/atom+xml;type=entry or
app:accept=applicationAtom.entry+xml)

--
Thomas Broyer

Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?

[Geoffrey Sneddon]

On 29 Nov 2006, at 19:17, Leons Petrazickis wrote:


We need to make the migration
from invalid XHTML to valid HTML5 very, very easy for them. We can't
require them to dig through PHP spaghetti. And that means that, no
matter how it's achieved,  needs to be valid HTML5.


+1


- Geoffrey Sneddon

WikiWikiWeb (was: Autodiscovery Draft Issues)

[Robert Sayre]

On 11/29/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:


James M Snell wrote:
> To document best practice as it relates specifically to syndication
> feeds.

It's not entirely clear what that actually means.  How would it be any
different from, or more useful than, existing documentation on the
subject that has been around for the past 3 or 4 years.


Well, it would be much less useful, since IETF documents don't have
pictures or unicode or translations.

With encouragement from the RSS-Public mailing list, I've taken their
Creative-Commons spec and pubilshed it here:

http://feedautodiscovery.org/

I removed the RFC 2119 reference, since I was told they were giving
"advice", and using SHOULD for it, which doesn't jive with the 2119
definitions.

Now, the Atom list should jump in and update the document so it does
justice to both formats. It's a wiki... just go for it.

(the CSS is a little rough still... I'll work on prettying it up)

--

Robert Sayre

Re: PaceEntryMediatype

[Eric Scheid]

On 30/11/06 5:39 AM, "Henry Story" <[EMAIL PROTECTED]> wrote:

> would that not be solvable by
> 
> 

not if you want to do this:



where 'something-else' might be 'comments' or 'history' or 'unexpurgated' or
'disemvowelled' or many other as yet unknown opaque-strings, some of which
would be used when linking to feed documents, some when linking to entry
documents.

e.

Autodiscovery IPR and Process Concerns

[Robert Sayre]

At this URL

http://www.snellspace.com/wp/?p=545

James Snell lists three issues concerning documenting Autodiscovery on
a wiki with a Creative Commons license.

1.) IP Protections

This is interesting for a couple of reasons. One is that Mr. Snell
previously claimed that the document has "nothing to do with my day
job" [1]. The second is the complete absurdity of worrying about IP
protections on HTML tags that make an orange button appear.

That said, we should take this seriously.

Do James Snell or IBM need to disclose any IP related to RSS and Atom
autodiscovery?

2.) Structured Process

Mr. Snell points at RFC2026. This is an individual draft. There is
basically no consistent process. Anyone who claims otherwise is trying
to deceive you. This group already has some good examples of the way
RFC2026 is interpreted in practice. It would be very disingenuous to
claim it constitutes structure.

3.) Well, whatever. ;)

a little confused,

Robert Sayre

[1] http://www.imc.org/atom-syntax/mail-archive/msg19142.html

Re: [rss-public] Autodiscovery IPR and Process Concerns

[James M Snell]

Robert Sayre wrote:
> [snip]
> 1.) IP Protections
> 
> This is interesting for a couple of reasons. One is that Mr. Snell
> previously claimed that the document has "nothing to do with my day
> job" [1]. The second is the complete absurdity of worrying about IP
> protections on HTML tags that make an orange button appear.
> [snip]

Good grief.

What I said was that my volunteering to take over the editing of the
autodiscovery draft had nothing to do with my day job;  that is, no one
at IBM asked me to work on autodiscovery nor am I aware of anything at
IBM that is dependent on its completion.  The only reason I volunteered
to serve as editor was because it was a loose end that hadn't been tied
up yet by the WG.

> Do James Snell or IBM need to disclose any IP related to RSS and Atom
> autodiscovery?

There's absolutely nothing to disclose.  I just prefer to limit my
material contributions to various standards activities to organizations
whose IP policies have been vetted and approved by my employer's IP
lawyers or to posts on my personal weblog.  Your wiki qualifies as neither.

> 2.) Structured Process
> 
> Mr. Snell points at RFC2026. This is an individual draft. There is
> basically no consistent process. Anyone who claims otherwise is trying
> to deceive you. This group already has some good examples of the way
> RFC2026 is interpreted in practice. It would be very disingenuous to
> claim it constitutes structure.
> 

I had originally suggested that the draft be resubmitted as a WG draft.
 The Area Director and the WG chairs suggested that since autodiscovery
was not covered under the original charter it would be better to pursue
it as an individual submission.  I decided to do so only on the
condition that the same open process used for the development of the
Atom and APP specs would be followed -- meaning that there would be no
closed door decisions and that clear consensus had to develop via open
discussions on the WG mailing list before any change to the document was
made.

> 3.) Well, whatever. ;)
> 
> a little confused,

Again, it would help if you quoted me accurately. My complete statement
can be found at [1].  All of the comments in my blog post were
specifically in regards to why I did not intend to participate in your
personal wiki documentation experiment. Good luck with it tho.

Now, to the WG as a whole: I really don't have any agenda for the
autodiscovery stuff other than to help foster it along.  If y'all think
there is a need for a I-D defining autodiscovery for Atom and APP, I've
got a few spare cycles to help with the editing.  If y'all think the
HTML5 stuff is sufficient, that's fine with me too.  If y'all want to go
some other direction with it, whatever.

- James

[1] http://www.snellspace.com/wp/?p=545

Re: PaceEntryMediatype

[James M Snell]

Mark Baker wrote:
> [snip]
> Yes, but more than that.  An entry document is, AFAICT, little more
> than shorthand for a feed with one entry, minus the feed-specific
> metadata.  It's processing is a subset of feed processing.  If the
> processing or content model of entry is extended, it applies to both
> feed documents and entry documents.
> 

Hmm.. I understand what you're saying but I don't think I agree.  In the
APP implementations I've put together, Feed and Entry documents
generally serve two entirely different purposes and are usually intended
for two entirely different audiences.

- James

Re: PaceEntryMediatype

[James M Snell]

John Panzer wrote:
> [snip]
 > +1 to doing this outside of APP (but concerned about deprecating...)
> [snip]

An I-D / RFC can update another RFC without deprecating the entire
thing.  In this case the hypothetical new document would deprecate only
the use of the application/atom+xml media type for Atom Entry Documents.
 The rest of RFC 4287 would be unaffected.

- James

Re: PaceEntryMediatype

[John Panzer]

So this needs a decision tree:

+1 to having some way to modify type= (either new media type, or 
appending ";type=entry", +0 to either)

  +1 to application/atom.entry+xml if new media type is used
+1 to doing this outside of APP (but concerned about deprecating...)

My use case:  A web page that contains both a blog entry, and the 
comments for that entry.  I want to be able to autodiscover alternates 
for both, using separate documents, for example:


title="This entry"/>
href="comments.xml" title="This entry's comments"/>


-John

James M Snell wrote:



http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

#pragma section-numbers off

== Abstract ==

For the current Atom Publishing Protocol draft...

Create a new media type for Atom Entry Documents: application/atomentry+xml

Deprecate the use of application/atom+xml for Entry Documents.

== Status ==

Proposed

== Rationale ==

The fact that one media type is used for both Feed and Entry documents
has repeatedly come up as a problem on more than one occasion.  We have
an opportunity to fix this problem now.

== Proposal ==

Add to Section 6.1

{{{
Atom Entry Documents are identified with the "application/atomentry+xml"
media type (See section 15).
}}}

Renumber existing section 15.3 to 15.4

Insert..

{{{
15.3 Content-type registration for 'application/atomentry+xml'

  MIME media type name:  application
  MIME subtype name:  atomentry+xml
  Mandatory parameters:  None.
  Optional parameters:
 "charset":  This parameter has semantics identical to the charset
parameter of the "application/xml" media type as specified in
[RFC3023].
  Encoding considerations:  Identical to those of "application/xml" as
 described in [RFC3023], Section 3.2.
  Security considerations:  As defined in this specification.
 In addition, as this media type uses the "+xml" convention, it
 shares the same security considerations as described in [RFC3023],
 Section 10.
  Interoperability considerations:  RFC 4287 registers the
 application/atom+xml Content-Type for both Atom Feed and Entry
 Documents.  For Atom Entry Documents, the use of the
 application/atom+xml type should be avoided.
  Published specification:  This specification.
  Applications that use this media type:  No known applications
 currently use this media type.

  Additional information:

  Magic number(s):  As specified for "application/xml" in [RFC3023],
 Section 3.2.
  File extension:  .atomentry
  Fragment identifiers:  As specified for "application/xml" in
 [RFC3023], Section 5.
  Base URI:  As specified in [RFC3023], Section 6.
  Macintosh File Type code:  TEXT
  Person and email address to contact for further information:
This specification's author(s)
  Intended usage:  COMMON
  Author/Change controller:  IESG
}}}

== Impacts ==


== Notes ==



CategoryProposals


 

Re: [rss-public] Autodiscovery IPR and Process Concerns

[Robert Sayre]

On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote:


There's absolutely nothing to disclose.


Are you sure about that?


I just prefer to limit my
material contributions to various standards activities to organizations
whose IP policies have been vetted and approved by my employer's IP
lawyers or to posts on my personal weblog.  Your wiki qualifies as neither.


Interesting. What is the difference between your personal weblog and a
wiki, in IP terms?

Keep in mind that a wise man once said "Anyone who uses the term
'Intellectual Property' is confused or trying to confuse you."



I had originally suggested that the draft be resubmitted as a WG draft.
 The Area Director and the WG chairs suggested that since autodiscovery
was not covered under the original charter it would be better to pursue
it as an individual submission.  I decided to do so only on the
condition that the same open process used for the development of the
Atom and APP specs would be followed -- meaning that there would be no
closed door decisions and that clear consensus had to develop via open
discussions on the WG mailing list before any change to the document was
made.


This entire paragraph is plainly false. All of the decisions you refer
to were made without consulting the WG, the community, or what have
you.



  If y'all think


Ah, this is what's called "innappropriately folksy". It's a common
rhetorical device used when the speaker wants to appear that they're
on the side of "the common man" or equivalent. The president of the
United States makes frequent use of this device.

Mission Accomplished!,

Robert Sayre

Re: PaceEntryMediatype

[Robert Sayre]

On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote:



John Panzer wrote:
> [snip]
 > +1 to doing this outside of APP (but concerned about deprecating...)
> [snip]

An I-D / RFC can update another RFC


I think John should edit.

--

Robert Sayre

Re: Autodiscovery IPR and Process Concerns

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2006-11-30 08:10]:
> On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote:
> >   If y'all think
> 
> Ah, this is what's called "innappropriately folksy". It's
> a common rhetorical device used when the speaker wants to
> appear that they're on the side of "the common man" or
> equivalent.

What rhetorical device is it to point out the rhetorical devices
used by other participants in a discussion?

> The president of the United States makes frequent use of this
> device.

What rhetorical device is it to use inappropriate and entirely
irrelevant political analogies in the hopes of derailing
a discussion?

Regards,
-- 
Aristotle Pagaltzis //