Re: Please review updated 1id-guidelines
Bruce Lilly wrote: * * The problem is that 1id-guidelines appears many places; there is one * version (and, yes, I mean the content of the various documents * differs; these are not merely mirrors) on the ISI.EDU ftp site in the * in-notes directory (where the RFCs live), another on the ftp.ietf.org * site in the ietf directory (as referenced by the RFC-Editor's web * site), and then there's the version at http://www.ietf.org/ietf (which The RFC Editor apologizes for not noticing this before. We have now deleted the ancient version /in-notes/1id-guidelines.txt from our directory. Our web page (howtopub.html) already does point to the latest IETF version (Bill Fenner's). RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 15 Mar 2005, at 21:25, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Media Type Specifications and Registration Procedures ' draft-freed-media-type-reg-02.txt as a BCP 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 iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12. I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: OLD: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. NEW: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, and provided the subtype is not defined for restricted usage, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. The addition of the framed encoding defined in section 4.8 is valuable now that media types are being widely used outside the traditional email environment. Since there are many media types defined to use RTP framing, and since RFC 3555 imposes additional registration requirements on these formats, it would be useful to reference it from within this draft. The following change to section 4.8 is one possible such edit: OLD: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames. Note that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols. Additional restrictions on 7bit and 8bit are given in [RFC2046]. NEW: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames and knowledge of the transport mechanism. Note ^ that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols. Additional restrictions on 7bit and 8bit are given in [RFC2046]. A commonly used transport with framed encoding is the Real-time ^^^ Transport Protocol, RTP. Additional rules for framed encodings ^^^ defined for transport using RTP are given in [RFC3555].
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 15 Mar 2005, at 21:25, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Media Type Specifications and Registration Procedures ' draft-freed-media-type-reg-02.txt as a BCP 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 iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12. I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. Thanks for taking the time to review it. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: OLD: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. NEW: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, and provided the subtype is not defined for restricted usage, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. The addition of the framed encoding defined in section 4.8 is valuable now that media types are being widely used outside the traditional email environment. Since there are many media types defined to use RTP framing, and since RFC 3555 imposes additional registration requirements on these formats, it would be useful to reference it from within this draft. The following change to section 4.8 is one possible such edit: OLD: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames. Note that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols. Additional restrictions on 7bit and 8bit are given in [RFC2046]. NEW: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames and knowledge of the transport mechanism. Note ^ that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols.
Re: IMS, IM-SSF
Questions on IMS should probably be directed towards 3gpp mailers, since that it is where it is being standardized. For SIP questions, you should direct your queries to sip-implementors@cs.columbia.edu, which is where general implementation help and QA takes place. For issues related to sip protocol design, please direct those to the sip list here at IETF, [EMAIL PROTECTED] To answer your question, I think you are perhaps talking about a call transfer. That is accomplished by sending a REFER request from the caller to the called party to transfer them. -Jonathan R. Nuno Novo wrote: In the IMS network when the Called party, after speaking with the Caller for a while, sends a BYE request there is a possibility for reconnecting the Caller to another called party (reconnect). The Caller is putted in a state of standby but is not disconnected. Caller à Called party 1--à Called party 2 The question is the following, when the second called party is contacted we need to connect the Caller to this new Called party, so how this is made? Is the Caller informed of the address of the new called party by a SIP UPDATE? Or this process is made in the MRCP that judges this call as a conference call? Regards, Nuno Novo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 12:57 PM To: Colin Perkins Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP [snip] I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Ned, how would you reconcile the current text in your document with the practice specified in RFC 3555? It's been alleged that the documents are not in alignment. -Scott- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 12:57 PM To: Colin Perkins Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP [snip] I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Ned, how would you reconcile the current text in your document with the practice specified in RFC 3555? It's been alleged that the documents are not in alignment. Assuming they really are out of alignment, I'd reconcile them by making whatever changes are appropriate in a revision to RFC 3555. Changing fundamental aspects of how media types are supposed to work and which vast tracts of code depend on is just not an option. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 18:30, [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 12:57 PM To: Colin Perkins Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP [snip] I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Ned, how would you reconcile the current text in your document with the practice specified in RFC 3555? It's been alleged that the documents are not in alignment. Assuming they really are out of alignment, I'd reconcile them by making whatever changes are appropriate in a revision to RFC 3555. Changing fundamental aspects of how media types are supposed to work and which vast tracts of code depend on is just not an option. The other changes I suggested were to align the draft with RFC 3555. This is a related change, primarily introduced because of the text/t140 type which is clearly textual data, but requires software to decode (and was registered under the RFC 3555 rules). Apologies if that wasn't clear. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 17:57, [EMAIL PROTECTED] wrote: ... The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: ... NEW: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, and provided the subtype is not defined for restricted usage, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. The example I have in mind in text/t140 which is UTF-8 text framed within RTP packets [RFC 2793]. The media type is defined only for use with RTP, and an agent that doesn't know how to decode RTP framing (i.e. a sequence of UDP packets with explicit time and ordering data) will never see the data. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date: 2005-04-12 11:58 From: Colin Perkins [EMAIL PROTECTED] I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). RFC 2793 states COMMON usage, not restricted, and makes no mention of any sort of restrictions under Interoperability considerations! RFC 2793 also says: Applications which use this media type: Text communication terminals and text conferencing tools. Surely when some content is reassembled from the individual packets, it can be presented without special purpose software (other than that required for charset issues and local presentation conditions). If it cannot be presented, it's difficult to imagine how the media type would be used in the stated intended applications. If a substantial amount (more than one MTU) of text/plain is transmitted via some application-level protocol over TCP (rather than RTP), one of course has to reassemble the content for the application layer for presentation. In what way does use of RTP instead of TCP (UDP, etc.) at a transport protocol layer change that? One might even ask in what sense -- at the application layer -- text/t140 is meant to be different from text/plain. Perhaps the issue is not so much with the registration procedure draft as with the text/t140 registration... or maybe RFC 2793 isn't a good example of the issue you have in mind. The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: Again, I'm not sure that helps for RFC 2793, which doesn't indicate restricted usage. OLD: Beyond plain text, there are many formats for representing what might [...] show subtypes of text to the user, while it is not reasonable to do present might be an improvement over show, as it accommodates text-to-speech conversion (for visually impaired users). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
On Fri, 8 Apr 2005, Scott W Brim wrote: On 4/7/2005 10:36, Brian E Carpenter allegedly wrote: Regardless of the interesting side-discussion about 'voting', what the toy shows after about a day is: prefer nroff: 8 prefer xml: 37 neither: 9 I wonder how many of those have actually written a draft using both? I have. I'm a recent convert to xml, and hugely prefer xml, to the extent that I have converted most resubmissions of mine from nroff to xml. Kireeti. --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 19:45, Bruce Lilly wrote: Date: 2005-04-12 11:58 From: Colin Perkins [EMAIL PROTECTED] I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). RFC 2793 states COMMON usage, not restricted, and makes no mention of any sort of restrictions under Interoperability considerations! RFC 2793 also says: Applications which use this media type: Text communication terminals and text conferencing tools. The encoding considerations section of the registration limits this to RTP. The lack of clarity on where to specify restricted domains of applicability is one of the things I hope this update to the media type registration guidelines will fix. Surely when some content is reassembled from the individual packets, it can be presented without special purpose software (other than that required for charset issues and local presentation conditions). If it cannot be presented, it's difficult to imagine how the media type would be used in the stated intended applications. If a substantial amount (more than one MTU) of text/plain is transmitted via some application-level protocol over TCP (rather than RTP), one of course has to reassemble the content for the application layer for presentation. In what way does use of RTP instead of TCP (UDP, etc.) at a transport protocol layer change that? One might even ask in what sense -- at the application layer -- text/t140 is meant to be different from text/plain. Perhaps the issue is not so much with the registration procedure draft as with the text/t140 registration... or maybe RFC 2793 isn't a good example of the issue you have in mind. An alternative example would be draft-ietf-avt-text-red-05.txt which, due to the way SDP/SIP signalling works, needs to use the same top level media type as text/t140. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date:Tue, 12 Apr 2005 19:03:03 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Sure, but if the display agent is unaware of the restrictions, it won't | ever be able to receive the media data. The example I have in mind in | text/t140 which is UTF-8 text framed within RTP packets [RFC 2793]. | The media type is defined only for use with RTP, I'm not sure I believe that works. What prevents this message from containing an alternative to the text/plain that is (currently) its only body type, with a Content-Type: text/t140 field (and correctly formatted for that, as much as it can be in a e-mailbody) ? Or what prevents a HTTP response with Content-Type: text/t140? Sure, the rules for use of that content-type may have been violated, but what is your MUA (or browser) supposed to do when it receives the message? All it is likely to know is that it has received yet another odd text/unknown content type. And if it is to be displayed, treating it just like all other text/weird types as the fallback (better than nothing) option ? I think Ned's point (though he can certainly speak for himself) is that if rfc3555 is allowing registrations like that, then rfc3555 needs to be fixed, and any bogus registrations that have been made, need to be corrected. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 20:51, Robert Elz wrote: Date:Tue, 12 Apr 2005 19:03:03 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Sure, but if the display agent is unaware of the restrictions, it won't | ever be able to receive the media data. The example I have in mind in | text/t140 which is UTF-8 text framed within RTP packets [RFC 2793]. | The media type is defined only for use with RTP, I'm not sure I believe that works. What prevents this message from containing an alternative to the text/plain that is (currently) its only body type, with a Content-Type: text/t140 field (and correctly formatted for that, as much as it can be in a e-mailbody) ? Or what prevents a HTTP response with Content-Type: text/t140? Sure, the rules for use of that content-type may have been violated, but what is your MUA (or browser) supposed to do when it receives the message? All it is likely to know is that it has received yet another odd text/unknown content type. And if it is to be displayed, treating it just like all other text/weird types as the fallback (better than nothing) option ? I think Ned's point (though he can certainly speak for himself) is that if rfc3555 is allowing registrations like that, then rfc3555 needs to be fixed, and any bogus registrations that have been made, need to be corrected. RFC 3555 allows media types to be defined for transport only via RTP. The majority of these registrations are under the audio and video top-level types, with a small number being under text. Is your objection to any media type being defined only for transport via RTP, or to text media types being defined only for transport via RTP? Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Voting (again)
Reading through the comments on voting I am struck by a difference in the approach people take to what the IETF is for. * One school of thought is that the reason for starting a working group is to arrive at a better engineering outcome than is possible independently. * Another school of thought is that the endorsement of a respected body will lead to deployment * The position I do not see argued is that the point of a working group is to establish the constituency required to deploy the proposal. As far as the first two positions go, I have made the mistake of beleiving in them in the past. These days I recognize that there are very few occasions where the way to arrive at an optimal solution is to get a group of 40 people together to work on it. WG process improves proposals in some respects, and is particularly valuable in ensuring that there is some sort of consistency in the general approach. But there are also serious negatives, a WG spec will inevitably be larger when it exits the working group and while the result is more likely to be consistent with legacy work the level of internal consistency will be less. I don't think that the imprimataur effect exists, if it did we would all be using IPv6, IPSec and DNSsec. And this problem is not limited to IETF, the ITU, W3C and OASIS all have the same issue. If you have a spec that has already established a critical mass a standard can help increase the size of the final deployment constituency. But that is not the hard part, the real hard part is getting to that critical mass. The real point of a working group process is to establish the coalition of support you need to get the work deployed. And this has to be taken into account when you are considering votes. All a hum tells me is who makes most noise. If I am sitting in a WG meeting and I vote for a particular proposal then the meeting knows that I have a level of commitment to that proposal. If the group votes the other way and I stay in the group even so there is another data point. In my book people who actually write code and deploy code have a rather bigger say in the typical decision than those who do not. If someone makes a proposal and the authors of the six major implementations and all the ISPs in the room vote against it then in my view the proposal isn't happening regardless of what the 'consensus' might be. The other really big problem with hums is that they can be very corrosive of trust in the chairs. The vote might have been in favor 40 to 10 and the chair assesed the hum as in favor and ten people still go to the bar thinking that the system is rigged. Hums lack auditability and as recent experience of machine voting in several countries has demonstrated auditability is the single biggest issue for a voting system as far as most voters are concerned. Large scale intimidation is pretty easy to pick up. The problem is even bigger when the chair decides to abuse their role. Why can't we elect the WG chairs? Why can't we elect the ADs? I feel absolutely no responsibility or duty towards officials that I have no part in electing and I don't think many other people do. There is a reason why the IESG is generally treated as if it was some sort of politburo, that is how people will relate to a body that is formed by a proceedure whose clear purpose is to distract the masses. The problem is that the IESG is not made up of Vint Cerf, Jon Postel and co any more. If people want to deploy IPv6 or IPSec or DNSsec or any of the other decades overdue technologies the IETF has grown infamous for delaying the only way it is going to happen is to hold a meeting with the stakeholders whose buy in is needed to deploy and to negotiate. Contrary to what some people believe the problems are not going to be solved by a more perfect document. Nor is refusing to hold such a meeting under IETF auspices going to stop such meetings happening, in fact they are going on already and the IETF is not being invited. The biggest problem with 'voting' is the tourism factor. A group can have a carefully worked out possition on a topic and then have it wrecked by a group of people coming into the room because they have heard about 'the issue' through the totally unbiased and accurate lens of a story on Slashdot. The way the system works in OASIS is that there is a con call every week or two weeks and members of the group have to attend the con calls to maintain voting rights. That system works really well, there is only one occasion that I know of where a group of wreckers were organized well enough to sink a rival group and that did not profit them any because the group simply decamped to another forum. The fact that people can leave and take their ball with them is the thing that makes the standards process work. It is absolutely not a failure of process that a group whose idea is rejected by the IESG can go off and work on it elsewhere. It is the only check to balance the whole system. The real
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 23:04, Robert Elz wrote: Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. You can put anything you like in a Content-Type header, but that doesn't make the data meaningful without a specification for the content. The restriction for only via RTP is made by only specifying the framing rules for RTP transport; the necessary information to convey the type via non-RTP transports is simply not specified. There are many (more than 50) such media types registered, and they are widely implemented without the problems at which you are hinting. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Wed, 13 Apr 2005, Robert Elz wrote: Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. What that means is that the specifications only supply instructions about how to format and transmit the data via RTP, not any other method. Therefore... That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. When you set out to do that, how are you going to figure out what some text/t140 content should be? Are you saying that you would use that Content-Type but just put US-ASCII into the body? You could also use Content-Type=audio/basic and put US-ASCII into the body, but it would probably not be very useful. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. Exactly so. This is why I've been pushing back on this. Stuff slops from one application/transport to another all the time. That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. Two points: (1) IMO text/t140 content actually conforms pretty well to the restrictions on the text top-level type. In particular, text/t140 material basically consists of unadorned UTF-8 text. There are a couple of control characters used for special purposes, but we're not talking about HTML here or anything similar. (2) The place where text/t140 parts ways with other media type usage is in how it is encoded. text/t140 cannot be encoded as a simple series of octets. Rather, it depends critically on RTP packet framing both to tie the content to other media and to eliminate duplicate material. We added the framed encoding type to the media type registration to take care of this and similar cases. A media type that uses the framed encoding really is confined to a particular transport realm. So, in the case of text/t140, I reallly don't see any conflict we need to resolve. But this doesn't mean there aren't potential conflicts - media types have been defined that work in both the packet and stream worlds. And such types could very easily leak - in fact I'd be surprised if they didn't. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
Dear Phillip, There is a motivation you forgot. It is to take control of your particular part of the world in using the IANA to lodge your vision and/or your name. Like a micro TLD Manager. This goes beyond impressing your commercial/political relations in having signed an RFC in their area - what you quote as the second motivation. You become a permanent acknowledged part of the core of the Internet metastructure. A part of the Internet Nobility. A new Larry Robert, Doug Engelbart, Louis Pouzin, Jon Postel, Vint Cerf jfc At 00:43 13/04/2005, Hallam-Baker, Phillip wrote: Reading through the comments on voting I am struck by a difference in the approach people take to what the IETF is for. * One school of thought is that the reason for starting a working group is to arrive at a better engineering outcome than is possible independently. * Another school of thought is that the endorsement of a respected body will lead to deployment * The position I do not see argued is that the point of a working group is to establish the constituency required to deploy the proposal. As far as the first two positions go, I have made the mistake of beleiving in them in the past. These days I recognize that there are very few occasions where the way to arrive at an optimal solution is to get a group of 40 people together to work on it. WG process improves proposals in some respects, and is particularly valuable in ensuring that there is some sort of consistency in the general approach. But there are also serious negatives, a WG spec will inevitably be larger when it exits the working group and while the result is more likely to be consistent with legacy work the level of internal consistency will be less. I don't think that the imprimataur effect exists, if it did we would all be using IPv6, IPSec and DNSsec. And this problem is not limited to IETF, the ITU, W3C and OASIS all have the same issue. If you have a spec that has already established a critical mass a standard can help increase the size of the final deployment constituency. But that is not the hard part, the real hard part is getting to that critical mass. The real point of a working group process is to establish the coalition of support you need to get the work deployed. And this has to be taken into account when you are considering votes. All a hum tells me is who makes most noise. If I am sitting in a WG meeting and I vote for a particular proposal then the meeting knows that I have a level of commitment to that proposal. If the group votes the other way and I stay in the group even so there is another data point. In my book people who actually write code and deploy code have a rather bigger say in the typical decision than those who do not. If someone makes a proposal and the authors of the six major implementations and all the ISPs in the room vote against it then in my view the proposal isn't happening regardless of what the 'consensus' might be. The other really big problem with hums is that they can be very corrosive of trust in the chairs. The vote might have been in favor 40 to 10 and the chair assesed the hum as in favor and ten people still go to the bar thinking that the system is rigged. Hums lack auditability and as recent experience of machine voting in several countries has demonstrated auditability is the single biggest issue for a voting system as far as most voters are concerned. Large scale intimidation is pretty easy to pick up. The problem is even bigger when the chair decides to abuse their role. Why can't we elect the WG chairs? Why can't we elect the ADs? I feel absolutely no responsibility or duty towards officials that I have no part in electing and I don't think many other people do. There is a reason why the IESG is generally treated as if it was some sort of politburo, that is how people will relate to a body that is formed by a proceedure whose clear purpose is to distract the masses. The problem is that the IESG is not made up of Vint Cerf, Jon Postel and co any more. If people want to deploy IPv6 or IPSec or DNSsec or any of the other decades overdue technologies the IETF has grown infamous for delaying the only way it is going to happen is to hold a meeting with the stakeholders whose buy in is needed to deploy and to negotiate. Contrary to what some people believe the problems are not going to be solved by a more perfect document. Nor is refusing to hold such a meeting under IETF auspices going to stop such meetings happening, in fact they are going on already and the IETF is not being invited. The biggest problem with 'voting' is the tourism factor. A group can have a carefully worked out possition on a topic and then have it wrecked by a group of people coming into the room because they have heard about 'the issue' through the totally unbiased and accurate lens of a story on Slashdot. The way the system works in OASIS is that there is a con call every week or two weeks and members of the group have to attend the con
RE: Voting (again)
Dear Phillip, There is a motivation you forgot. It is to take control of your particular part of the world in using the IANA to lodge your vision and/or your name. Like a micro TLD Manager. Folk greatly overestimate the effectiveness of IANA as a control point. Why does the IESG think that it is a good idea to make it difficult to get SRV prefix assignments? They should be assigned automatically. There is no shortage of SRV prefixes, there is a finite number of TCP/IP port numbers. It makes absolutely no sense to make folk grovel and submit an RFC and get it through the IESG just to get a prefix assigned. I didn't do this for my non IETF protocols, I just made the prefixes up myself. The chance of an accidental collision is infintesimal and could be eliminated entirely if the allocation process was made sane. Nobody is going to tread on my prefixes for the good reason that if they do their protocol will break. Same goes for DNS RR assignments, if a breakaway group wants a new RR and the IANA refuses, what happens next? If someone decides they are going to use RR 42 and start doing so on any extended scale nobody else will want it - not unless RRs become a scarce resource. I come from a culture where the foundation myth consists of strange women lying around in ponds distributing swords. Authority is a myth that only has substance as long as people agree to believe in it. This goes beyond impressing your commercial/political relations in having signed an RFC in their area - what you quote as the second motivation. You become a permanent acknowledged part of the core of the Internet metastructure. A part of the Internet Nobility. A new Larry Robert, Doug Engelbart, Louis Pouzin, Jon Postel, Vint Cerf jfc Yes, but those people are all known for innovating and producing 'stuff'. Getting your name on an RFC does not make you Vint Cerf. Becoming chair of the IETF does not make you Vint Cerf either. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
WG Action: Conclusion of Voice Profile for Internet Mail (vpim)
The Voice Profile for Internet Mail WG (vpim) in the Applications Area has concluded. The IESG contact persons are Ted Hardie and Scott Hollenbeck. The mailing list will remain active. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification' to Proposed Standard
The IESG has approved the following documents: - 'Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification ' draft-ietf-ccamp-gmpls-recovery-functional-04.txt as a Proposed Standard - 'Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) ' draft-ietf-ccamp-gmpls-recovery-terminology-06.txt as an Informational RFC - 'Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) ' draft-ietf-ccamp-gmpls-recovery-analysis-05.txt as an Informational RFC These documents are products of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This set of documents presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in subsequent documents. Working Group Summary The WG had a consensus on advancing these documents and addressed AD-review comments. Protocol Quality These documents have been reviewed for the IESG by Alex Zinin. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
