Re: Last Call: draft-ietf-insipid-session-id-reqts-08.txt (Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks) to Informational RFC
I don't have that spec in front of me, but if it is used directly, that would reveal personally identifiable information. I would hope it is used as input into a hash out something. The solution spec we're developing would certainly not use such a value directly or allow it to be derived. Paul Original Message From: SM s...@resistor.net Sent: Sat Sep 14 12:03:30 EDT 2013 To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-insipid-session-id-reqts-08.txt (Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks) to Informational RFC At 09:40 10-09-2013, The IESG wrote: The IESG has received a request from the INtermediary-safe SIP session ID WG (insipid) to consider the following document: - 'Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks' draft-ietf-insipid-session-id-reqts-08.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-24. Exceptionally, comments may be Section 4.5 of the draft discusses about logging. It mentions that creating a common header field value through all SIP entities will greatly reduce any challenge for the purpose of ... communication tracking. I look a quick look at Reference [6]. It mentions that the IMEI shall be used for generating an identifier. Is the IMEI covered by REQ4? Regards, -sm
RE: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger-10.txt (WebFinger) to Proposed Standard
Got it. Thanks! I'll make that change. Paul -Original Message- From: Alissa Cooper [mailto:acoo...@cdt.org] Sent: Thursday, March 21, 2013 9:45 AM To: Paul E. Jones Cc: ietf@ietf.org; apps-disc...@ietf.org; webfin...@ietf.org Subject: Re: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger- 10.txt (WebFinger) to Proposed Standard I suggest adding the sentence without the word implicitly. The result would be: Further, WebFinger MUST NOT be used to provide any personal information to any party unless explicitly authorized by the person whose information is being shared. Publishing one's personal data within an access-controlled or otherwise limited environment on the Internet does not equate to providing authorization of further publication of that data via WebFinger. Thanks, Alissa On Mar 20, 2013, at 9:28 PM, Paul E. Jones pau...@packetizer.com wrote: Alissa, It was suggested that we remove the word implicit. I'm OK with removing it. If we did that, would you want to add this new sentence or a modified version of it? Paul -Original Message- From: apps-discuss-boun...@ietf.org [mailto:apps-discuss- boun...@ietf.org] On Behalf Of Alissa Cooper Sent: Monday, March 18, 2013 11:31 AM To: ietf@ietf.org Cc: apps-disc...@ietf.org Subject: Re: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger- 10.txt (WebFinger) to Proposed Standard Given how little control Internet users already have over which information about them appears in which context, I do not have a lot of confidence that the claimed discoverability benefits of WebFinger outweigh its potential to further degrade users' ability to keep particular information about themselves within specific silos. However, I'm coming quite late to this document, so perhaps that balancing has already been discussed, and it strikes me as unreasonable to try to stand in the way of publication at this point. Two suggestions in section 8: s/personal information/personal data/ (see http://tools.ietf.org/html/draft-iab-privacy-considerations- 06#section-2.2 -- personal data is a more widely accepted term and covers a larger range of information about people) The normative prohibition against using WebFinger to publish personal data without authorization is good, but the notion of implicit authorization leaves much uncertainty about what I imagine will be a use case of interest: taking information out of a controlled context and making it more widely available. To make it obvious that this has been considered, I would suggest adding one more sentence to the end of the fourth paragraph: Publishing one's personal data within an access-controlled or otherwise limited environment on the Internet does not equate to providing implicit authorization of further publication of that data via WebFinger. Alissa On Mar 4, 2013, at 3:24 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'WebFinger' draft-ietf-appsawg-webfinger-10.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ No IPR declarations have been submitted directly on this I-D. ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
RE: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger-10.txt (WebFinger) to Proposed Standard
Alissa, It was suggested that we remove the word implicit. I'm OK with removing it. If we did that, would you want to add this new sentence or a modified version of it? Paul -Original Message- From: apps-discuss-boun...@ietf.org [mailto:apps-discuss- boun...@ietf.org] On Behalf Of Alissa Cooper Sent: Monday, March 18, 2013 11:31 AM To: ietf@ietf.org Cc: apps-disc...@ietf.org Subject: Re: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger- 10.txt (WebFinger) to Proposed Standard Given how little control Internet users already have over which information about them appears in which context, I do not have a lot of confidence that the claimed discoverability benefits of WebFinger outweigh its potential to further degrade users' ability to keep particular information about themselves within specific silos. However, I'm coming quite late to this document, so perhaps that balancing has already been discussed, and it strikes me as unreasonable to try to stand in the way of publication at this point. Two suggestions in section 8: s/personal information/personal data/ (see http://tools.ietf.org/html/draft-iab-privacy-considerations- 06#section-2.2 -- personal data is a more widely accepted term and covers a larger range of information about people) The normative prohibition against using WebFinger to publish personal data without authorization is good, but the notion of implicit authorization leaves much uncertainty about what I imagine will be a use case of interest: taking information out of a controlled context and making it more widely available. To make it obvious that this has been considered, I would suggest adding one more sentence to the end of the fourth paragraph: Publishing one's personal data within an access-controlled or otherwise limited environment on the Internet does not equate to providing implicit authorization of further publication of that data via WebFinger. Alissa On Mar 4, 2013, at 3:24 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'WebFinger' draft-ietf-appsawg-webfinger-10.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ No IPR declarations have been submitted directly on this I-D. ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
RE: [apps-discuss] Last Call: draft-ietf-appsawg-webfinger-10.txt (WebFinger) to Proposed Standard
Hannes, I was hoping that some of the remarks that I provided last year (e.g., http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html) would help to clarify the content of the document. That didn't quite happen... Yeah, I wasn't copied. In earlier versions of the document I had the impression that the acct: URI scheme always had to be used as input to the lookup process but as Section 4.5 explains this is not necessary. The resource parameter may contain other URIs as well. Section 4.5 does not give a lot of description of when certain URIs are utilized. Correct, any URI might be used. That does not mean that the server will respond for every URI, but some wanted acct and email and tel URIs, for example. Also, using an HTTP URI could be used to return additional information about a URI. For example, in Section 3.1 the example talks about a user receiving an email from b...@examle.com and this email address is then used by WebFinger but the request example shows an acct: URI scheme (rather than a mailto URI). It seems that there is the unstated assumption (at least in that example) that the mailto URI is the same as the acct: URI, which of course isn't necessarily the case. I believe it would be good to state these assumptions to avoid confusing the reader. Fair point. How about immediately following the example, we add: 'Note the assumption made in above example that there is an acct URI for the given mailto URI. This is not always the case.' Think about it: If you receive a SIP URI (which also has an email alike structure with a username @ domain part) that does not mean either that you can use this as an email address either. In some rare cases you might. That's definitely true. However, this is one reason for encouraging the use of the acct URI scheme, though. In general (though not always), there is account associated with the user. The SIP URI, mailto URI, etc., each have a user part. I believe it is a reasonable assumption that there *may be* an 'acct' URI for the user. If not, WF will return nothing. We intended WF to be useful to humans, too, which means that if a user sees pau...@packetizer.com, the user will assume that might be a means of reaching paulej at packetizer.com using any number of tools (email, XMPP, H.323, etc.). They would be correct for most. Thus, there is encouragement for WF servers to use the acct URI. If you believe that everyone would get the difference anyway (because the URI scheme determines the semantic of the identifier) then have a look at the Google WebFinger page (see http://code.google.com/p/webfinger/). At least these guys don't understand the difference either. There was even a proposal that we use no URI scheme at all and merely have the user@domain identifier. However, there is value in using a proper URI with WF, since querying h323:pau...@packetizer.com might return the address of my Gatekeeper, for example, versus the information that would be returned for my account. In general, I am wondering whether there are additional assumptions implied about the URI scheme associated with the identifier in the lookup mechanism. For example, the text in Section 3.3 talks about email client configuration and it seems that the requestor is interested in receiving information about the email configuration based on the resource=mailto... URI scheme usage. If I use a different URI scheme (like a aaa: URI scheme) would my response look different? Yeah, it might look different. What a WF server wishes to return for a given URI is really up to the administrator. It might be that the same information is returned for any given URI scheme having the same user@domain part, but the server could return different responses. Then, there is a question about the lack of privacy considerations in the document. We do have quite a bit of text in the security considerations section. This will be called out more clearly with sub-sections, but there are at least three full paragraphs on privacy, even going to the point of providing the example that sharing location information might put a person in danger from someone who wishes to inflict harm on them. Personally, I thought that went a bit overboard, but that text was requested, so it's there. The usage of the WebFinger mechanism requires the requestor to have access to the full username@domain identifier. While this may be OK in some cases when the response relates very much to the specific user account it may be a problem in other cases. For example, in the OAuth case there is the idea that the user identifier may be hidden from the relying party but you have just required that identifier to be provided to the relying party to start the entire OAuth exchange (in the discovery). WF is not for use with every protocol, so I cannot address OAuth generically. However, WF *is* used as a part of OpenID Connect. So, yes, the
RE: Internet Draft Final Submission Cut-Off Today
Dale, Personally, I'd trust date -u much sooner than any random person. Even better: $ date --date='00:00 Feb 26, 2013 UTC' Mon Feb 25 19:00:00 EST 2013 $ Funny thing is when I try the date from the announcement: All Final Version (-01 and up) submissions are due by UTC 24:00 Monday, February 25. I get this: $ date --date='24:00 Feb 25, 2013 UTC' date: invalid date `24:00 Feb 25, 2013 UTC' Seriously, what the heck is 24:00? Is that like the meeting we'll have in the afternoon at about 13:90? Paul
RE: Internet Draft Final Submission Cut-Off Today
Joes, Then again, having these deadlines at all is a bit silly. It just forces authors to informally distribute updates directly on the list, and cuts off access to work that doesn't need to happen in sync with an IETF meeting. I agree with your point to a large extent, but I'm sure there are reasons. On the one hand, having a cut-off time could help WG chairs make a decision as to whether to entertain a discussion on a draft. On the other hand, having no cut-off date might mean that drafts are submitted extremely late and it makes it more challenging or impossible to prepare an agenda. Perhaps having a soft cut-off is more reasonable. If the document is late, then it would be up to the WG chair to decide whether to entertain it. If there are no documents by the deadline, the chair could decide to cancel the meeting. What one would not want, though, are hundreds of drafts submitted the night before the IETF meeting starts with some expectation of discussion time. Paul
RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
But it does clue one in immediately to the fact that the parameter is non-standard. Paul -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Nottingham Sent: Tuesday, March 06, 2012 11:11 PM To: Randy Bush Cc: Randall Gellens; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice On 07/03/2012, at 1:52 PM, Randy Bush wrote: To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to X-? I think one of the main points of the draft is to answer that question with no. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice
I suppose one could argue that X- should never be on the Public Internet, anyway. But they are. If we remove X-, then what will happen is developers will use names that don't have X-. Will that make things better? No. I'd argue it will make it worse. Non-standard extensions do present issues, that's no in question. However, killing X- will only mean other values will be used. At least X- can be ignored. I'm not going to throw up a roadblock to the draft. Call for the end of X- if you want, but I know it will not stop introduction of non-standard values in protocols, so a problem will remain. One way to help this is to get standards through the IETF faster. Some take forever. Paul -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Wednesday, March 07, 2012 12:57 AM To: Paul E. Jones Cc: 'Randy Bush'; 'Randall Gellens'; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice Yes, but (as the draft tries to explain) putting this kind of metadata in a name is prone to issues, because it can change -- i.e., when a header (or other protocol element) becomes standard. On 07/03/2012, at 4:54 PM, Paul E. Jones wrote: But it does clue one in immediately to the fact that the parameter is non-standard. Paul -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Nottingham Sent: Tuesday, March 06, 2012 11:11 PM To: Randy Bush Cc: Randall Gellens; ietf@ietf.org Subject: Re: Last Call: draft-ietf-appsawg-xdash-03.txt (Deprecating Use of the X- Prefix in Application Protocols) to Best Current Practice On 07/03/2012, at 1:52 PM, Randy Bush wrote: To me, the target of that language is software that generically treats protocol elements beginning with x- in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. clue bat please? is there any general semantic to X-? I think one of the main points of the draft is to answer that question with no. -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
Mark, Generally, it's hard for me to be enthusiastic about this proposal, for a few reasons. That doesn't mean it shouldn't be published, but I do question the need for it to be Standards Track as a general mechanism. I believe standards track is appropriate, since the objective is to define procedures that are interoperable and the specification defines a set of procedures that would be implemented by multiple software products. Mostly, it's because I hasn't really seen much discussion of it as a general component of the Web / Internet architecture; AFAICT all of the interest in it and discussion of it has happened in more specialised / vertical places. The issues below are my concerns; they're not insurmountable, but I would have expected to see some discussion of them to date on lists like this one and/or the TAG list for something that's to be an Internet Standard. You might be right that more discussion has happened off the apps-discuss list, but I would not equate that with not being a component of the web architecture. On the contrary, host-meta has a lot of utility and is an important building block for the web architecture. With host-meta, it is possible to advertise information in a standard way, discover services, etc. Some of the latter is not fully defined, but cannot be defined without this standard in place. * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. XRD is not complicated. It's an XML document spec with about seven elements defined. In order to convey metadata, one must have some format defined and XRD is as good as any other. I don't think the use of XRD should be considered as negative aspect. OpenID uses (through Yadis) a precursor to XRD called XRDS. I'm not sure about Oauth's usage of XRD. Either way, does this matter? * Precedence -- In my experience one of the most difficult parts of a metadata framework like this is specifying the combination of metadata from multiple sources in a way that's usable, complete and clear. Hostmeta only briefly mentions precedence rules in the introduction. I assume you are referring to the processing rules in 1.1.1? How would you propose strengthening that text? * Scope of hosts -- The document doesn't crisply define what a host is. This might be deliberate and not really fault of this document. The hostname that we are all used to using for a host may or may not refer to a physical host. It might refer to a virtual host or a virtually hosted domain. In any case, this term is consistent with the term used on the HTTP spec and the header line Host:. * Context of metadata -- I've become convinced that the most successful uses of .well-known URIs are those that have commonality of use; i.e., it makes sense to define a .well-known URI when most of the data returned is applicable to a particular use case or set of use cases. This is why robots.txt works well, as do most other currently-deployed examples of well-known URIs. Defining a bucket for potentially random, unassociated metadata in a single URI is, IMO, asking for trouble; if it is successful, it could cause administrative issues on the server (as potentially many parties will need control of a single file, for different uses -- tricky when ordering is important for precedence), and if the file gets big, it will cause performance issues for some use cases. All of the use cases are not defined, but the host-meta document provides some examples, such as finding the author of a web page, copyright information, etc. There has been discussion of finding a user's identity provider. The particular uses. Each of these examples fits well within the host-meta framework. It builds upon the web linking (RFC 5988) work you did in a logical and consistent way, and I see these as complementary documents. To your concern, host-meta is flexible, but the functionality is bounded. * Chattiness -- the basic model for resource-specfic metadata in hostmeta requires at least two requests; one to get the hostmeta document, and one to get the resource-specific metadata after interpolating the URI of interest into a template. This is true, but the web is all about establishing links to other information. I view this is a good thing about host-meta: it provides a very simple syntax with a way to use well-defined link relation types to discover other information. For some use cases, this might be appropriate; however, for many others (most that I have encountered), it's far too chatty. Many use cases find the latency of one extra request unacceptable, much less two. Many use cases require fetching metadata for a number of distinct resources; in
RE: RFC 4612 - historic status
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 -Original Message- From: Frank Ellermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 2:55 AM To: ietf@ietf.org Subject: Re: RFC 4612 - historic status 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 4612 - historic status
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. 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 isnt my responsibility to go try to do my day job and coordinate between multiple standards organizations. Paul From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 1:56 AM To: Paul E. Jones Cc: [EMAIL PROTECTED]; 'Brian E Carpenter'; ietf@ietf.org Subject: Re: RFC 4612 - historic status Paul E. Jones wrote: I wonder how customers might react to seeing new gateway hardware producedutilizing 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 4612 - historic status
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 -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 3:53 AM To: Brian E Carpenter; Eliot Lear Cc: Paul E. Jones; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: RFC 4612 - historic status --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 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, 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
RE: RFC 4612 - historic status
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 PROTECTED] Sent: Thursday, August 10, 2006 2:13 PM To: Brian E Carpenter Cc: ietf@ietf.org Subject: Re: RFC 4612 - historic status Brian E Carpenter wrote: Historically, documenting for reference produces an Informational status, rather than Historic. 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. 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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question on SIP versus H.323 Multimedia teleconferencing
Dan, H.323 has not done poorly. In fact, it is the most widely used standards-based call control protocol. The largest chunk of VoIP traffic in the world is carried over H.323-based networks. Even now, H.323 is finding new markets that SIP has only begun to touch. SIP is missing a number of critical components necessary to really make it carrier-class. There are many misunderstandings about H.323 and most companies didn't care: after all, they were out selling H.323 products very well and ignored the incorrect marketing hype. So, the entire paragraph about this standard did poorly is false and SIP looks like a winner is likewise false. That's not to say that SIP is a failure: it's just that it has not met with the same market success as H.323 (yet-- I suspect it will one day). Definitely, Microsoft is planning to roll it out in XP and that will excite a few people. At the same time, it will put a few companies out of business as Microsoft's SIP proxy will become the defacto-standard. I have not seen pricing, but I would bet it will be extremely inexpensive. The result of this roll-out will force many out of business or force them to change their business strategy. Because the Internet is a poor medium for IP Telephony, many people will not even use it.. just as few used NetMeeting for VoIP. What usage it got was primarily for data capabilities. Of course, there will be some usage, but I suspect that most VoIP traffic will still come from dedicated hardware (IP phones, residential GWs, infrastructure equipment, etc.) Supporting H.323 through a firewall is not terribly complex and SIP suffers from the same problem: layer 3 addresses are carried in the application layer. These are quite comparable. For a more thorough comparison of H.323 and SIP, visit: http://www.packetizer.com/iptel/h323_vs_sip/ Best Regards, Paul On Wed, 15 Aug 2001, Dan Kolis wrote: Greetings, I'm trying to put together a programme regarding multimedia telecom and have been working with H.323. My perception is this standard did poorly due to generally insufficient bandwidth, a small universe of QoS and hard to support port usage. On the other hand, SIP looks like a winner the same way bluetooth did. That is, the blemishes only show when the thing exists. Supporting H.323 through a firewall/proxy seems intrinsically difficult. On the other hand, the wildcard port usage might have subtle value in scalability. I gather SIP is more old school, like a telnet session, more or less containing more complex objects; (speech, etc). Any opinions on this? I'm not complaining but am observing the zero length attached viruses in my attachment directory from this list just passed 100! Regards to All Dan K
Re: SIP phones
A few manufacturers are listed here: http://www.packetizer.com/sip/sip_links.html Paul - Original Message - From: "Gaurang Kalyanpur" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 21, 2000 11:31 AM Subject: SIP phones I am looking for a SIP phone (physical unit) or a SIP user agent (Software driven). Does anybody know where I can buy one. I would prefer a physical unit, but a software emulation is also an option. Thanks GK
