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?
It means that one standards body has decided to cite a specification
that has been deprecated by another.
It would have been
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
--On Monday, 14 August, 2006 08:56 +0200 Brian E Carpenter
[EMAIL PROTECTED] 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?
It means that one standards body has
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
--On Monday, 14 August, 2006 03:41 -0400 Paul E. Jones
[EMAIL PROTECTED] wrote:
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
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
Brian
The details of whether one branch of the MIME tree or another
is best suited for the application is definitely more suitable for the
RAI area.
The fact that this problem is not discussed in the RFC
and the historic designation is misleading,
is a good subject for this list.
I personally
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,
John,
Without wishing to comment on the specifics of RFC 4612...
On 14 Aug 2006, at 09:13, John C Klensin wrote:
--On Monday, 14 August, 2006 03:41 -0400 Paul E. Jones
[EMAIL PROTECTED] wrote:
Brian,
The problem with using image is that it would mean that a
gateway would have to do one of:
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
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.
Paul E. Jones wrote:
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
The real
If what I am reading is correct it sounds like the real design mistake here was
putting semantics into content types in the first place.
A code point registration should be just that, registration of a unique
identifier to prevent confusion. Once people start adding semantics into the
John C Klensin wrote:
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
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.
Then you're not reading the document correctly. For one thing, there isn't an
IETF tree any longer - it's now
If what I am reading is correct it sounds like the real design mistake here
was putting semantics into content types in the first place.
No, the mistake is in reading more into the very limited semantics of top level
types than was ever intended. As Harald says, the way SDP uses top level types
From: Ned Freed [mailto:[EMAIL PROTECTED]
If what I am reading is correct it sounds like the real
design mistake
here was putting semantics into content types in the first place.
No, the mistake is in reading more into the very limited
semantics of top level types than was ever
Brian E Carpenter wrote:
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.
The problem, Brian, is that the discussion is about IETF process,
Jorge - Let me ask, who eats a copyright violation claim against the IETF???
Is it the IETF?, the IESG? or is it the Document Publisher - who for a while
longer is ISI? - my bet is that in this case that's ISI because the
publisher has a fiduciary responsibility to address the DMCA Take Down
Dear Joyce,
I thank you for your response.
jfc
At 21:50 14/08/2006, Joyce Reynolds wrote:
Jefsey,
1) Expedited process of documents for RFC publication is not encouraged
for the reason you mentioned: ...one cannot expedite one particular
RFC publishing process, by-passing and delaying all the
The IESG has received a request from the Cross Registry Information Service
Protocol WG to consider the following document:
- 'A Lightweight UDP Transfer Protocol for the the Internet Registry
Information Service '
draft-ietf-crisp-iris-lwz-06.txt as a Proposed Standard
The IESG plans to
The IESG has received a request from the Cross Registry Information Service
Protocol WG to consider the following document:
- 'A Common Schema for Internet Registry Information Service Transfer Protocols
'
draft-ietf-crisp-iris-common-transport-03.txt as a Proposed Standard
The IESG plans to
The IESG has received a request from the Cross Registry Information Service
Protocol WG to consider the following document:
- 'XML Pipelining with Chunks for the Information Registry Information Service
'
draft-ietf-crisp-iris-xpc-04.txt as a Proposed Standard
The IESG plans to make a
The IESG has approved the following document:
- 'Mounting Web Distributed Authoring and Versioning (WebDAV) servers '
draft-reschke-webdav-mount-05.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact
24 matches
Mail list logo
