Subject: RFC 4612 - historic status

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 9 Aug 2006 12:03:01 +0200

According to RFC 2026 historic RFCs are those whose
specification has been superceded by a more recent specification.
 
RFC 4612 is labeled historic, and defines a MIME type
for T.38 over RTP, a practice that is just now being adopted
and to be encouraged.
 
Indeed, the RFC discusses limitations of UDPTL,
but it does not suggest deprecating its use.
In any case the subject of the RFC is the RTP mode,
and not UDPTL.
 
So why the "historic" designation?
 
Y(J)S
 
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Aug 2006 02:28:19 -0700

> So why the "historic" designation?
 From the announcement of IESG approval:

This document was Last Called as Proposed Standard in the past, but
review by the Audio Video Transport Working Group and the
IESG led to concern that the format not become a precedent
for future media types.  The specification should be
published and available for registration, and the media-type should
be registered, but only because these are required for a very specific
application  within ITU SG 16's T.38's real-time fax support.
This application is described in the document as a "legacy".
The Historic designation does not imply that the legacy
application should not be operative with this specification and
registration to support it, but only that there not be *future*
designs, non-legacies, based on this precedent.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Aug 2006 02:28:19 -0700

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Aug 2006 11:28:26 +0200

Because the IESG believed that specifying an image format
as an audio subtype was to be discouraged, but should be documented
for reference.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=42143

The standard MIME type for T.38 is image/t38 (RFC 3362).

    Brian

Yaakov Stein wrote:
> ------------------------------------------------------------------------
> 

M8
	for [email-masked]; Wed, 09 Aug 2006 05:28:32 -0400
Date: Wed, 09 Aug 2006 11:28:26 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Yaakov Stein <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC 4612 - historic status

Because the IESG believed that specifying an image format
as an audio subtype was to be discouraged, but should be documented
for reference.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=42143

The standard MIME type for T.38 is image/t38 (RFC 3362).

    Brian

Yaakov Stein wrote:
> ------------------------------------------------------------------------
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 9 Aug 2006 17:13:18 +0200

> Because the IESG believed that specifying an image format as an audio
subtype was to be discouraged, but should be documented for reference.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&
id=42143

> The standard MIME type for T.38 is image/t38 (RFC 3362).

I would agree if T.38 were an image type. It isn't.

The image format for group 3 faxes is given in T.4 and NOT in
T.30 (procedures for group 3 over PSTN) or T.38 (procedures for group 3
over IP).

Furthermore, T.38 specifically states that it  
"defines the procedures to be applied to allow Group 3 facsimile
transmission between terminals 
where in addition to the PSTN or ISDN a portion of the transmission path
used between terminals includes an IP 
network, e.g. the Internet."

Note the statement "in addition to the PSTN ...".
T.38 presupposes that if one wants to transfer an image
over an IP network, then one would send an image file.
 
What T.38 does is to relay the T.30 fax (audio signals)
across an IP network.

In any case, as there is no IESG note at the beginning, 
and no mention of the image/t38 MIME type anywhere,
the IESG's intent is not clear from the RFC.

On the contrary, one gets the feeling that the use of RTP
is being declared historic, leaving UDPTL.

Y(J)S

---

From: Dave Crocker <[email-masked]>
Date: Wed, 09 Aug 2006 07:24:24 -0700

> as an audio subtype was to be discouraged, but should be documented

Historically, "documenting for reference" produces an Informational status,
rather than Historic.

>From RFC 2026:
> 4.2.2  Informational
> 
>    An "Informational" specification is published for the general
>    information of the Internet community, and does not represent an
>    Internet community consensus or recommendation.

Why the change for this document?

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Aug 2006 17:23:21 +0200

> Historically, "documenting for reference" produces an Informational status,

Yes, and the idea was to make a stronger statement than "for reference".
iirc, we considered briefly approving it for Informational and then
immediately reclassifying it as Historic. But that seemed silly.

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Aug 2006 11:12:59 -0700

> immediately reclassifying it as Historic. But that seemed silly.

If the IETF wanted to "make a statement" why not merely add text that makes the
desired statement?

Again, this has been the usual approach.  Why change from that?

Going to Informational and then Historic would, indeed, be silly.  It confuses
the semantics of Informational, since it implies that Informational has some
sort of standards status.

The model that has the IETF focus heavily on matters of "precedence",
particularly with respect to specifications that are not standards track, seems
questionable, at best.  It means that rather than relying on questions of
technical efficacy, scaling, and the like, the IESG is instead worrying about
future, hypothetical, unstated human abuses.

At the least:
> concern that the format not become a precedent
> for future media types

should produce explicit text added to the document, so that readers can
understand whatever problems there are with this approach.

d/
-- 

  Dave Crocker

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Aug 2006 23:09:45 -0400

Dave,

This is the second document this year that I published through the IETF that
was classified as "historic".  The was RFC 4351.

In both cases, I was working in the ITU on fax and modems issues and with
people looking for a way to efficiently transport modulated signals between
two PSTN gateways over IP.  For both cases, consideration was given to:
  1) We needed a way to provide security
  2) We were working with a narrow scope (GW to GW)
  3) We wanted something that would not be resource intensive
  4) We wanted to minimize signaling requirements

Since, for all intents and purposes, "fax" signaling or "text" signaling
between two PSTN gateways is nothing more than an alternative representation
of "audio", it was decided that we would define a means of switch media
types on the fly.  The reasoning seems good, engineers liked it, and the
standards were approved (ITU-T Rec. T.38 and ITU-T Rec. V.151).

We were able to meet all of the above (and other) requirements using this
method.  For the folks I worked with, it was really no different than
sending RFC 2833 to represent DTMF.  (There are known differences in the
media characteristics, such as a change in bandwidth usage, transmission
rates, etc.  However, all of those aspects were well understood and not
really subject matter for these RFCs, anyway.)

We could have elected to not publish RFC 4351 and simply include it in ITU-T
V.151.  Now, we have an "historic" document in the IETF referenced by a
brand new international standard published by the ITU.  Now, that is silly.
To some extent, I regret having presented the text to the IETF in the first
place.

In the case of the audio/t38 document (RFC 4612), this was written only
because, if I read RFC 4288 correctly, such a document is needed to register
a MIME type in the IETF tree.

In the case of MIME, we could have used a different tree (e.g.,
audio/itu.t38).  However, as far as I know, there is no such tree.
Secondly, while it might be easy to get such a tree, there are various SDP
parameters and other such things the ITU has defined in recommendation
(e.g., V.150) for which there are no "trees".  I like symmetry.

For those SDP parameters to which I refer (ITU-T Rec. V.150 being one such
standard containing unregistered parameters), the IETF has apparently
refused to publish an RFC for at least one SDP parameter (gpmd).  This
leaves the industry in a very awkward situation, since we have SDP
parameters appearing in ITU standards that are not registered with IANA.

The short of it is that the cooperative spirit and the process are broken to
some degree.  I don't have my favorite standards body, though I have worked
in many of them like a good number of the other folks in the IETF.  So,
don't assume I'm arguing from one side or another.  I'm just an engineer
caught in the middle of standards-making organizations trying to get my job
done.

I wonder how customers might react to seeing new gateway hardware produced
utilizing "historic" RFCs.  What does that mean?

Paul

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Thursday, August 10, 2006 2:13 PM
> To: Brian E Carpenter
> Cc: [email-masked]

---

From: "todd glassey" <[email-masked]>
Date: Sun, 13 Aug 2006 20:25:58 -0700

Mr. Jones - welcome to the smoke screen. What you are finding is that this
IETF does not have most of the formal infrastructure that its documents
allude to. It has no formal method of creating Informational Filings and in
all instances passes them off as Historic as though only genesis that
happens within the IETF counts in this world.

Understand some of my frustration at trying to get other key entities to
adopt processes with the IETF when they have no

    1)     process for inducting information from external sources that is
published for reference and not for development or respect for copyrights of
contributors, or those filing for informational purposes where there is no
copyright conveyance beyond joint-publication rights.

    2)    process for accepting formal notice of anything relative to this
thing called erroneously a Request For Comments (which based on IETF
processes could be called an Internal Technology Vetting Document since it
really isn't a 'request for anything' but rather a proclamation for people
to base other things on.

    3)    method at the organizational level of cross-collaboration on
anything with anyone... there have been some unusual instances in various
WG's where cross-collaboration between other externals and the WG occurred
on a project level; but at the organizational and more importantly the
brand-recognition level - this IETF has nothing really implemented to
address these needs.

Ah well...

todd glassey
----- Original Message ----- 
From: "Paul E. Jones" <[email-masked]>
To: <[email-masked]>; "'Brian E Carpenter'" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 13, 2006 8:09 PM
Subject: RE: RFC 4612 - historic status

> > particularly with respect to specifications that are not standards
track,
> > seems

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 Aug 2006 07:55:37 +0200

> utilizing "historic" RFCs.  What does that mean?

The statement from the IESG is that it means you did something you ought
not to have done.  I believe we are now quibbling over the word
"audio".  What I don't understand is why you didn't have this discussion
with the RAI and APP folk *before* the document was released and come up
with a mutually agreeable alternative.  A spirit of cooperation would
demand no less, right?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Aug 2006 08:56:35 +0200

>>utilizing "historic" RFCs.  What does that mean?

It means that one standards body has decided to cite a specification
that has been deprecated by another.

It would have been better, imho, if ITU had decided to cite the non-deprecated
image/* MIME types, but that is not a decision the IETF can control.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Aug 2006 09:36:38 +0200

Paul E. Jones wrote:
> Eliot,
> 
>  
> 
> So, this is a difference of opinion.  There is no process in place through
> which such things can be discussed at organization/organization level.  The
> IETF does not have a formal liaison process like the ITU, ETSI, or other
> standards bodies.  There is a liaison process, as I understand it. but it
> has not worked so far, as far as I know.

It has worked frequently, but both ITU and IETF being large and complex,
there can always be oversights. Please contact our lead liaison to
ITU-T, Scott Bradner, if you want to follow up on this.

    Brian

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 14 Aug 2006 03:41:21 -0400

Brian,

The problem with using "image" is that it would mean that a gateway would
have to do one of:
1) Close the audio session and open an image session
2) Open a second "image" session during mid-call
3) Open both an audio session and image session at the outset

For a lot of reasons, none of those options are preferred.  In the latter
case, gateways just waste memory and CPU resources servicing sockets that
are never used.  In the first two cases, there is a lot of extra signaling
on the wire.  (For SIP networks, and especially IMS-based SIP networks, this
is horrible due to the widespread use of UDP, slow timer expiration, and
multiple hops through many proxies.  Use of UDP and moderate packet loss, or
even TCP with light packet loss and several proxy hops, could cause a fax
call to fail due to timer expiration.)

What was preferred, instead, is detecting the fax tone and then sending a
payload type that is recognized as "fax" as negotiated during the initial
offer/answer exchange.

Paul

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, August 14, 2006 2:57 AM
> To: Eliot Lear
> Cc: Paul E. Jones; [email-masked]; [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Aug 2006 03:53:25 -0400

--On Monday, 14 August, 2006 08:56 +0200 Brian E Carpenter
<[email-masked]> wrote:

> Eliot Lear wrote:
>> Paul E. Jones wrote:
>> 
>>> I wonder how customers might react to seeing new gateway
>>> hardware produced utilizing "historic" RFCs.  What does that
>>> mean?
> 

Brian,

I don't know the history of this, but it seems to me that, while
the IETF can't "control" the decision, there are extensive
provisions in the Liaison relationship with ITU that should
prevent such things from happening, or at least that should
prevent anyone involved from being surprised when they do.
Surprises are bad.  In my opinion at least, the primary role of
a liaison relationship is to prevent the other body from being
surprised: one may not always agree, but one should reasonably
expect to agree to disagree rather than having an action taken
that appears unpredictable.    It sounds to me from Paul's note
as if there was surprise here and surprise, to me, implies that
either someone was falling down on the job or, less likely,
deliberately ignoring clear signals.

I suspect that, had I known about this and paid attention, I
would have agreed with the general thrust of the IESG decision:
I still believe that there is some advantage in differentiation
among the top-level media types for which knowledge of subtype
is needed to do anything useful.  Unlike what Paul seems to
imply by his assertion that the signaling mechanisms are
essentially audio because they are analogous to DTMF tones, I
believe those non-text top-level types are differentiated by the
base capability that is required to _render_ the type, while the
subtype determines what is needed to interpret it so that it can
be rendered.  On that basis, fax has been considered an image
type since MIME was first defined.  So the questions this raises
for me about about procedures and how we work with other
organizations, not about whether giving this document a
deprecated status was appropriate.

So...

(1) Were the relevant ITU groups told, in a timely and
unambiguous way, about the IESG ("IETF") concerns about the
registrations and media types involved here?
 
(2) Did they respond in a useful way?  If so, was there any
consideration given to including a summary of the dialog, or a
reference to it, in the RFC-published document(s).

(3) Was there any attempt made to incorporate text into the
document or, if necessary, to publish a separate document,
explaining the concerns?  Such an arrangement would presumably
give the reader an understanding of the issues rather than
relying on the reader to notice a maturity level classification
and then interpret it as meaning that the IETF did not recommend
its use.

(4) As I read it, RFC 2026 is quite clear that one can combine a
maturity level of Informational or even Standards Track with a
recommendation level of "Limited Use" or "Not Recommended" [RFC
2026, Sections 3.3(d) and (e)].  Was that option considered?
While we have, de facto, defaulted all protocol-specification
RFCs to "Elective", the recommendation level machinery still
exists in RFC 2026 and, as far as I know, no effort has been
made to remove or deprecate it.

If the answers to the questions above are "no", then why not?
Can we fix things at this point, presumably by publishing a
brief A/S explaining the issues and assigning a "limited use" or
"not recommended" status (presumably all of the needed
information is in the tracker) and then reclassifying the
subject documents as Informational... since it clearly provides
information about a media type that is in active use, however
well- or ill-advised that use might be?

And, to raise a much broader question out of context, should the
various documents that describe and specify RFC documentation
(charters, RFPs, etc.) have been modified, in the wake of
effective elimination of STD 1, to require that recommendation
levels be included in RFC indexes and other relevant materials.

     john

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 14 Aug 2006 03:31:28 -0400

Eliot,

So, I could come over as an individual and asked a question, I suppose.
However, would it matter what that answer is?  I am not a liaison officer
between organizations.  In short, it isn't my responsibility to go try to do
my day job and coordinate between multiple standards organizations.

Paul

  _____  

From: Eliot Lear [mailto:[email-masked]] 
Sent: Monday, August 14, 2006 1:56 AM
To: Paul E. Jones
Cc: [email-masked]; 'Brian E Carpenter'; [email-masked]
Subject: Re: RFC 4612 - historic status

Paul E. Jones wrote: 

The statement from the IESG is that it means you did something you ought not
to have done.  I believe we are now quibbling over the word "audio".  What I
don't understand is why you didn't have this discussion with the RAI and APP
folk before the document was released and come up with a mutually agreeable
alternative.  A spirit of cooperation would demand no less, right?

Eliot

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Aug 2006 04:13:16 -0400

--On Monday, 14 August, 2006 03:41 -0400 "Paul E. Jones"
<[email-masked]> wrote:

> Brian,
> 
> The problem with using "image" is that it would mean that a
> gateway would have to do one of:
> For a lot of reasons, none of those options are preferred.  In
> the latter case, gateways just waste memory and CPU resources
> servicing sockets that are never used.  In the first two
> cases, there is a lot of extra signaling on the wire.  (For
> SIP networks, and especially IMS-based SIP networks, this is
> horrible due to the widespread use of UDP, slow timer
>...

Paul,

I think there may be a fundamental misunderstanding, or at least
difference in understanding, about top-level media types implied
in the above.  From a process standpoint, if you are just
finding out about it now, something has, IMO, failed (see my
other note).  But, putting that aside...

The "text/" top-level type, and only the "text/" top-level type
has the property that one can reasonably expect to be able to
display the contents to the user without understanding the
subtype.  Whether that is realistic or not, and how narrowly
that requirement should (or must) be interpreted to make
something "text/" has been widely debated in the past.

But, for all other media types, one cannot interpret them
without both the top-level type and the subtype.  As far as
transmission issues are concerned, the type-subtype distinction
is largely irrelevant: there is not, meaningfully, an "audio
session" or an "image session" as far as the media type is
concerned.   Where they do become somewhat relevant is at the
receiving end: if I don't have any way to render any image, then
an image type is, at best, going to need to be stored for later
retrieval even if it were to be fully understood.  Similarly for
audio: if the recipient does not have the capability to
reproduce or otherwise render sounds, then one can only store
the transmission contents for future processing or forward it
elsewhere (or reject the transmission on that basis).

A gateway that isn't structured around that model -- a model
that, at its most general, implies that the transmission forms
of media types are more or less just bits except to the network
end-points -- isn't necessarily wrong, but it will have far more
problems interworking smoothly and with minimal information loss
than the names of media types or the status attached to them.

regards,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Aug 2006 11:22:41 +0200

I suggest that instead of disturbing a couple of thousand people
with this discussion, it would be profitable to take it up
with the RAI Area Directors. They certainly know more about it
than I do.

     Brian

Paul E. Jones wrote:
> John,
> 
> In the case of RFC 4612, I was not terribly surprised given the fact that
> RFC 4351 had already gone through the same discussion.  In any case, the ITU
> had long finished its work on T.38 before the IETF completed its work on the
> audio/t38 registration.  T.38 does not reference RFC 4612, obviously.
> 
> In the case of RFC 4351, that was a surprise and I argued with a few folks
> over the decision to make it historic.  However, I lost the argument.
> However, losing the argument does not change the minds of those doing work
> in the ITU.  I did report the situation to folks in the ITU and there was
> serious consideration given to just not publishing the IETF text at all OR
> just re-publishing it and not referencing the IETF text.  (V.151 now
> references RFC 4351, which I think was the best outcome in spite of the
> "historic" status.)
> 
> I will not disagree with the beauty of media type separation.
> 
> Nonetheless, I think it is important to consider the fact that the different
> organizations have different ways at looking at a problem.  The IETF views
> voice and DTMF as "audio", video as "video", fax as "image", and TTY/TDD
> tones as "text".  If I were to implement a PC application, that would all
> make perfect sense.
> 
> But, what do we call video with embedded text sub-titles?
> What is the difference between "image" and "voice" to a gateway that is
> responsible for receiving signals from a PSTN circuit, transporting those
> over IP, and delivering those back to a PSTN circuit?
> 
> If one has a rack of gateway boxes that provide service to 100,000 DS0s, how
> much additional money does the buyer want to pay in order to cleanly
> separate those media streams received over that circuit?  Cost was
> definitely a consideration in the decision-making process.
> 
> I'm still beside myself that folks are willing to say that DTMF is a special
> case of audio, while fax or text tones received from a switched circuit are
> not.  Following the logic of separating text and fax, DTMF should have been
> separated and placed into the call signaling path.
> 
> In any case, as I said: I'm more or less the guy caught in the middle of two
> organizations with differing opinions.  The IETF can do what it wants.  The
> ITU can do what it wants.  At the end of the day, we are all scrambling to
> get the aging SIP stuff to work in the face of Skype dominating the market
> ;-)
> 
> My point: doing something the most architecturally "pure" way does not
> necessarily lead to profit or success in a reasonable time frame.
> Compromises must be made and progress must be hastened.  By the time you get
> it all working the "right" way, technology will change, values will change,
> and applications will change.  This is probably much less true for
> transport-layer matters than applications.  Applications can be quite
> flexible.
> 
> The nice thing about applications is that they can change over time.  While
> audio and fax might be sent over the same RTP session today (they are not,
> BTW: today, fax is sent as "image/t38" and it's very painful and entirely
> insecure), that can be changed over time to operate over a separate path
> (cleanly).  It may or may not be RTP by then, because perhaps that might
> also change.  Perhaps fax will disappear completely.  Perhaps a fax machine
> will be a device that has a keyword that allows one to enter an e-mail
> address, scan pages, and transmit TIFF or PDF files.  Perhaps the World's
> preferred file formats might also change.  Perhaps it will be Microsoft's
> new XPS?
> 
> Paul
> 
> 
>>From: John C Klensin [mailto:[email-masked]]
>>Sent: Monday, August 14, 2006 3:53 AM
>>To: Brian E Carpenter; Eliot Lear

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 14 Aug 2006 05:00:44 -0400

John,

Paul

---

From: Colin Perkins <[email-masked]>
Date: Mon, 14 Aug 2006 11:01:21 +0100

John,

Without wishing to comment on the specifics of RFC 4612...

On 14 Aug 2006, at 09:13, John C Klensin wrote:
> concerned.

This is not correct when it comes to RTP sessions signalled using  
media types in SIP/SDP. In those cases, Paul is correct that the  
session is negotiated to convey only one top level media type (e.g.  
only audio), and switching to an image format would require a  
separate session.

Discussion of why this is the case should probably happen on the AVT  
mailing list, since that is the working group responsible for RTP, or  
on rai-discuss.

Colin

---

From: JFC Morfin <[email-masked]>
Date: Mon, 14 Aug 2006 10:31:12 +0200

Dear Todd,
what is specified/you ask is logic. But the pluses of the IETF also 
come from not being that formal. Some kind of fuzzy logic. I thought 
for a while it could be corrected by the users from inside (hence my 
involvement). I hoped we would have less difficulties like this one, 
less ethical problems, less affinity groups and more practical 
diversity, and not to wait for a mid-term judgment by the market.

 From my experience - in particular with languages and OPES - I think 
now that the usership contribution should be organised differently. 
We would need one or several users systems groups, building 
_complete_ system logics (distributed/used as such), shopping their 
specifications among the different SSDOs, interacting with all of 
them and the IETF, and bringing some crosspolinization. This is what 
W3C, this is what ICANN, this is what UNICODE, etc. partly do. But 
none of them targets a complete network operating system and 
environment, bringing the need of a complete model of reference. I 
think you could be among those investigating that.

I hoped the IAB mailing list on a future architecture could help 
this. This is why I said I was only interested by an architecture by 
usage (as we start seeing the Multilingual Internet implemented). 
Because it permits some kind of fuzzy architecture, accepting 
different visions, and supporting simultaneous evolutions. It went so 
far as shortly discussing the need of a/several network OS(es). But 
the debate died.

jfc

---

From: "todd glassey" <[email-masked]>
Date: Mon, 14 Aug 2006 06:09:52 -0700

The problem is Brian - that there is this underlying assumption with the
entire IETF service model that says that people are responsible for
maintaining their own alignment with IETF standards - and so at some point
they decide they have spent enough and they stop spending to participate.
Personally its an amazingly arrogant assumption that the world is going to
continue paying the IETF, whether through the donation of engineering
services to the WG's or by subsidizing attendance and/or a standards program
initiative or their freezing a product at some level which stops tracking
new IETF changes. Either way  for innovation and tracking its new standards
as such this is the problem, and believing that the current model does not
need wholesale change documents how naive the IETF management model is IMHO.

If there was a Copyright Issue such that people were forced to stay in
compliance with the IETF then this would not be an issue. At least at the
Standards Tracking levels; but this is the point behind Brand Control - and
you folks have lost it.

It (Brand Control for the IETF) is not hiding - its standing right in front
of you too - all you have to do is take control of the Copyright, work out
some better process for sharing and interacting with the ITU, ANSI, ETSI and
a couple of others like WIPO,  and create some simple method of versioning
that is tied to the copyrights.

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Cc: "Paul E. Jones" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Sunday, August 13, 2006 11:56 PM
Subject: Re: RFC 4612 - historic status

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Aug 2006 15:47:34 +0200

> 3) Open both an audio session and image session at the outset
The real underlying problem was that the idea of an "audio session" was 
a design mistake.

Practice has shown that sessions consist of multiple media.

Unfortunately the IETF hasn't fixed that design mistake, so the ITU has 
kluged around it with things like "audio/t34".

My opinion. And yes, the discussion of how to recover from that mistake 
belongs in the RAI area.

                    Harald

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Aug 2006 07:49:45 -0700

John C Klensin wrote:
> base capability that is required to _render_ the type, 

RFC2046:
>     (3)   audio -- audio data.  "Audio" requires an audio output
>           device (such as a speaker or a telephone) to "display"
>           the contents.  An initial subtype "basic" is defined in
>           this document.

As Paul indicated, T.38 is used between gateways.

The receiving gateway turns the data into a telephone call.

In what way does this not satisfy *exactly* the requirements for the audio
top-level MIME type?

d/
-- 

  Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Aug 2006 07:56:31 -0700 (PDT)

> a MIME type in the IETF tree.

Then you're not reading the document correctly. For one thing, there isn't an
"IETF tree" any longer - it's now callled the "standards tree". As for
publication requirements, the text is pretty clear:

  4.10 Publication Requirements

  Proposals for media types registered in the standards tree by the IETF itself
                                                             ^^^^^^^^^^^^^^^^^^
  MUST be published as RFCs. RFC publication of vendor and personal media type
  proposals is encouraged but not required. In all cases the IANA will retain
  copies of all media type proposals and "publish" them as part of the media
  types registration tree itself.

Note the added emphasis - when the IETF has to publish any registrations it
makes in an RFC. This requirement is specific to the IETF, not to other
standards bodies.

  As stated previously, standards tree registrations for media types defined in
  documents produced by other standards bodies MUST be described by a formal
  standards specification produced by that body. Such specifications MUST contain
  an appropriate media type registration template taken from Section 10.
  Additionally, the copyright on the registration template MUST allow the IANA to
  copy it into the IANA registry.

Other standards bodies are in turn enjoined to put their registrations in
whatever sort of formal specifications they produce.

The point here is that registrations in the standards tree have to be formally
published in some way. For the IETF that means they have to appear in an RFC
since that's the formal publication mechanism the IETF has. Other standards
bodies all have their own mechanisms and should be used as appropriate.

Now, since the IESG has to approve these registrations and has considerable
leeway as to the what's allowed, nothing prevents them from asking for a
descriptive RFC for the type if they feel such a document is appropriate. The
obvious case that comes to mind is where an IETF specification and some
specification done elsewhere are intertwined in some way. But this sort of
thing would be an IESG action, not a process requirement.

> audio/itu.t38).

There are really only media types; MIME merely defined the system first. And
ever since separate trees were introduced the rule has always been that
creating a new tree requires standards action. (There's also a very substantial
process specification burden associated with defining a new tree.)

> However, as far as I know, there is no such tree.

Correct. My original plan was to define a "standards tree" separate from the
existing "IETF tree" with a prefix of something like "std." for other standards
bodies to use. This plan was rejected for various reasons and the IETF tree was
renamed to the standards tree instead and other standards bodies were
encouraged to use it.

> (e.g., V.150) for which there are no "trees".  I like symmetry.

First, definining a tree is perhaps the most difficult activity in this entire
space. The main change in RFC 4288 is the rejiggering of the IETF/standards
tree, and getting this document through the process proved to be a decidedly
nontrivial exercise.

Second, the tree mechanism was very intentionally embedded in the subtype name.
It serves as a visual reminder for people dealing with the type in
specifications and processes. It is not intended to be a structural mechanism
for software to use. So the fact that this isn't structurally visible in
protocols is intentional, and the notion that there's a symmetry issue makes no
sense at all.

				Ned

---

From: "todd glassey" <[email-masked]>
Date: Mon, 14 Aug 2006 11:39:03 -0700

No Brian - this is NOT an issue of internal WG problems - its an issue of
how the IETF interacts and uses or contributes to other SDO's efforts. That,
if not proper for this mailing list is important and should be heard - so
where do conversations in regard to organizational failings of the IETF go
if not [email-masked]?

Todd Glassey

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "'John C Klensin'" <[email-masked]>; <[email-masked]>; "'Eliot Lear'"
<[email-masked]>; <[email-masked]>
Sent: Monday, August 14, 2006 2:22 AM
Subject: Re: RFC 4612 - historic status

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Aug 2006 07:56:48 -0700

> with the RAI Area Directors. They certainly know more about it

The problem, Brian, is that the discussion is about IETF process, including a
serious question about decision(s) by the IESG.

That is rather more broad than the RAI area.

d/
-- 

  Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Aug 2006 08:54:35 +0200

Dave Crocker wrote:

>> | audio -- audio data.  "Audio" requires an audio output
>> |          device (such as a speaker or a telephone) to
>> |          "display" the contents.  An initial subtype
>> |          "basic" is defined in this document.
[...]
> In what way does this not satisfy *exactly* the requirements
> for the audio top-level MIME type?

The final receiver isn't supposed to "hear" a fax arriving as
phone call, "whistling" the replies.  Seriously, does this 
media type require a modem somewhere on the receiver's side ?

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Aug 2006 10:53:39 +0200

> That is rather more broad than the RAI area.

I don't see the process issue. Snipping from the Last Call, it was perfectly
clear what the IESG planned to do.

>> Subject: Last Call: 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type 
>>          Registration' to Historic 
...
>> The IESG has received a request from an individual to consider the 
>> following document:
>> 
>> - 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration '
>>    <draft-jones-avt-audio-t38-05.txt> 
>> 
>> for future media types.  It should be registered because it is
>> required for a very specific application within ITU SG 16's
>> T.38's real-time fax support, but shown in the RFC as literally
>> a legacy.
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send any comments to the
>> [email-masked] or [email-masked] mailing lists by 2005-11-11.

     Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Aug 2006 22:20:32 -0700

Brian,

Brian E Carpenter wrote:
>> The problem, Brian, is that the discussion is about IETF process, including
>> a serious question about decision(s) by the IESG.
...
> clear what the IESG planned to do.

There are two different process issues, here.  Neither of them involves a
"process violation".  By that, I mean, it does not appear that the formal steps
were violated. So this is not a question of initiating an appeal or the like.

Again, I'll observe that the issues are larger than the RAI area:

1.  What should have been a simple process instead became complex, took a long
time, and produced a result that is at best questionable and at worst silly.
(Well, no.  At worst it was extremely damaging, because it discourages further
use of the IETF.) As easy as it might be to fault the ITU folks for not
realizing that they did not need to get an RFC published, I'll note that a) it
is not appropriate for us to expect others to know the subtle intricacies of our
workings, and b) it appears that they were not the only ones who failed to
understand what is and is not required.

2.  The community does not expect to be required to carefully read every Last
Call, to check for the possibility that the IESG is taking an exceptional and
action. Last Calls are usually issued for a review of the work, not IESG plans
for disposition of the work.  In fact, Last Calls usually are issued before the
IESG has considered the tiem.  So there is a minor question of bringing such
issues to the attention of the community rather more proactively, or at least
more distinctively.

Both of these points are much more broad than the technical question that the
RAI area might be appropriate to pursue.

(However, I am intrigued by a number of postings that suggest that the
underlying technical problem is due to a strategic MIME technical administration
error, within an RAI working group.  This might make it problematic to expect
that area to deal with the particulars of the T.38 "solution".)

d/

ps. I can't resist noting how ironic it is that I'm trying to help any activity
involving T.38, given that I've never liked T.38 and given how much energy I put
into the T.37 (fax emulation via email) work.  But I decided to add this comment
by way of making clear that my concerns are not with T.38, but with the slow and
frustrating process the ITU folks were subjected to, and the questionable
outcome that resulted.  The IETF regularly proves to be remarkably hostile about
groups that come to us and ask for assistance.

-- 

  Dave Crocker

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 17 Aug 2006 21:16:27 -0400

Frank,

No, it does not.  It's simply an alternative representation of the fax data.
The receiver could receive it and print it, create audio tones (if it
desired), produce a TIFF image and e-mail it, or whatever else it wished to
do.

Paul

> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Tuesday, August 15, 2006 2:55 AM
> To: [email-masked]