From apps-review-bounces@ietf.org Thu Nov 08 12:46:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBSu-0002D6-Jp; Thu, 08 Nov 2007 12:46:52 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IqBSs-0002Cb-VS for apps-review-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:46:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBSn-00023S-Mm for APPS-REVIEW@ietf.org; Thu, 08 Nov 2007 12:46:45 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBSk-0005Qh-8A for APPS-REVIEW@ietf.org; Thu, 08 Nov 2007 12:46:45 -0500 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 320ED142211 for ; Thu, 8 Nov 2007 09:46:41 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqILx5uVhweX for ; Thu, 8 Nov 2007 09:46:32 -0800 (PST) Received: from [192.168.1.103] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BE996142203 for ; Thu, 8 Nov 2007 09:46:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <29D3BB6B-F99E-4968-BE7B-992949C47032@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: APPS-REVIEW@ietf.org From: Lisa Dusseault Date: Thu, 8 Nov 2007 09:46:31 -0800 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [APPS-REVIEW] BEHAVE draft affecting Apps protocols X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org This draft seems to talk a lot about how application protocols are affected. Can somebody review it in the next week or so? It will be on the IESG agenda in one week (thursday 8:30 am PST), so that would be the ideal time for the authors to have a collected list of last issues to address. http://tools.ietf.org/html/draft-ietf-behave-p2p-state-05 Thanks, Lisa _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review From apps-review-bounces@ietf.org Mon Nov 12 05:18:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWN7-0007Oh-Su; Mon, 12 Nov 2007 05:18:25 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IrWN6-0007NL-G0 for apps-review-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 05:18:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWN0-000715-MD for APPS-REVIEW@ietf.org; Mon, 12 Nov 2007 05:18:18 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrWMw-00040G-Rp for APPS-REVIEW@ietf.org; Mon, 12 Nov 2007 05:18:18 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 12 Nov 2007 10:18:11 +0000 Message-ID: <47376610.5090206@isode.com> Date: Sun, 11 Nov 2007 20:29:04 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lisa Dusseault Subject: Re: [APPS-REVIEW] BEHAVE draft affecting Apps protocols References: <29D3BB6B-F99E-4968-BE7B-992949C47032@osafoundation.org> In-Reply-To: <29D3BB6B-F99E-4968-BE7B-992949C47032@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: APPS-REVIEW@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Lisa Dusseault wrote: > This draft seems to talk a lot about how application protocols are > affected. Can somebody review it in the next week or so? It will be > on the IESG agenda in one week (thursday 8:30 am PST), so that would > be the ideal time for the authors to have a collected list of last > issues to address. > > http://tools.ietf.org/html/draft-ietf-behave-p2p-state-05 Hi Lisa, I can't claim to be an expert on NATs, however I've reviewed the document and found that it is well written and it seems to contain a fairly detailed description of various NAT traversal techniques in use today. I don't believe it adds any new requirements on application protocols which were not already created previously by NATs. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review From apps-review-bounces@ietf.org Thu Nov 15 12:50:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsirG-00014b-Jq; Thu, 15 Nov 2007 12:50:30 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IsirG-00013c-7J for apps-review-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 12:50:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsirF-000125-SC for apps-review@ietf.org; Thu, 15 Nov 2007 12:50:29 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isir8-0008Fs-Ii for apps-review@ietf.org; Thu, 15 Nov 2007 12:50:29 -0500 Received: from [192.168.2.3] ([72.54.167.34]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lAFHnEsI026600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2007 09:49:17 -0800 Message-ID: <473C870C.9020404@dcrocker.net> Date: Thu, 15 Nov 2007 11:51:08 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gonzalo.Camarillo@ericsson.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 507ad05d8e517f8285c14ade4dc3acf0 Cc: apps-review@ietf.org Subject: [APPS-REVIEW] Review of draft-ietf-sip-body-handling-00.txt X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org (re-post, undery my apps-review subscription address. /d) This is a review of draft-ietf-sip-body-handling-00.txt. The document states that its goal is to 'clarify' the handling of message bodies in SIP and to mandate details of MIME "encoding" of bodies. On their face, both of these are worthy tasks, with a history of having been useful when provided for other protocols. The current draft seems to mix a number of activities: 1. Basic tutorial coverage of material from other specifications. Sometimes this is quite basic. Its inclusion raises the question of what required background is expected of readers? If very basic material is needed, why is there relatively little of it? It might help for the document to make an explicit statement about the background that is expected of the reader, and the types of simple pedagogy that are included (and why). That is, where is the reader expected to start from and where will this document's purely instructional material take the reader to? 2. Clarification in the sense of pointing out key aspects of other specifications that are relevant to the handling of SIP message bodies, possibly including statements about non-obvious implications. In effect, this type of material is also instructional, but not about the basics. Rather than essentially regurgitating or restating existing material, as Activity #1 does, this type of material, documents implications that are not obvious and well might not have been written before. (This is exactly the added insight that experience provides, of course, and is what motivates documents like this.) 3. Assertion of normative specification details. These might fix problems, expand functionality, or adapt the functionality to the idiosyncrasies of the SIP environment. All 3 activities can provide significant assistance. I suppose that the document seeks to do a job for SIP that is similar to what RFC1123/RFC1122 did for a variety of protocols in the late 1980s? General Comments ================ The document mixes its 3 activities, which I found confusing. Sometimes there seems to be normative intent, without normative language and sometimes there is normative language (should or may) without normative intent. When there appears to be normative intent, I assume that the document is trying to build upon details from other, existing specifications, but the document does not cite the specific sections of text that it is modifying or building upon. Sometimes I was not sure which activity a given segment of text was attempting to perform. I suspect the document will benefit from some re-organization, according the the activity being performed. A sequence of basic pedagogy, followed by new insights and implications, followed by refining or modifying normative specification could make things much clearer to the reader. In general, it appears that SIP has taken MIME constructs and profiled them into an incompatible, overlap with email MIME, just as Web MIME did, but possibly more dramatically. To the extent that SIP's use of MIME is incompatible with nearly 15 years of using MIME for email (and the web) the document should probably make explicit statements about the differences. If these are already stated elsewhere, the document should cite the relevant text. Offhand, I'd guess it would help to explain the reasons for the incompatibilities, so that readers do not assume that the choices were arbitrary. (This is a version of explaining implications that is not in the current document but that I think fits into its goal nicely.) On the open matter of constraints about when MIME references are allowed, I do not have a resolution to recommend. I think it needs to be determined by a clear statement of the requirements/constraints that are causing the issue to be an issue. The thread I read covered some of this, but I did not see working group consensus on a summary. That is, if you are going to change from the pre-existing use of MIME references, there are processing concerns that prompt the change. They should be documented and maybe rank-ordered. In effect, you need to say how SIP is providing a different environment in which references are being used and, therefore, what constraints this different environment is imposing. Detailed Comments ================= I'll apologize for choosing to include the entire document. I decided that this makes it much easier to see the context of the comments. In addition, comments occur regularly enough so that trying to cut out bits would not shorten things much... > SIP Working Group G. Camarillo > Internet-Draft Ericsson > Expires: March 1, 2008 August 29, 2007 > > > Message Body Handling in the Session Initiation Protocol (SIP) > draft-ietf-sip-body-handling-00.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware have been > or will be disclosed, and any of which he or she becomes aware will be > disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. Note that other groups > may also distribute working documents as Internet- Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months and > may be updated, replaced, or obsoleted by other documents at any time. It > is inappropriate to use Internet-Drafts as reference material or to cite > them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on March 1, 2008. > > Copyright Notice > > Copyright (C) The IETF Trust (2007). > > Abstract > > This document clarifies how message bodies are handled in SIP. "Clarifies" implies states implications. > Additionally, it discusses to which degree SIP user agents need to support > MIME (Multipurpose Internet Mail Extensions)-encoding of body parts. CHANGE last sentence: --> Additionally, it specifies SIP user agent support for MIME in message bodies. (More direct statement. This is normative. /d) > > > > > > > > Camarillo Expires March 1, 2008 [Page 1] > Internet-Draft Message Body Handling in SIP August 2007 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. > Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. > Multipart Message Bodies . . . . . . . . . . . . . . . . . . . 3 3.1. > General Considerations . . . . . . . . . . . . . . . . . . 4 3.2. Body > Generation . . . . . . . . . . . . . . . . . . . . . 5 3.3. UAS Behavior > . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message-body and > Body-part Disposition . . . . . . . . . . . . 6 4.1. Body Generation . . > . . . . . . . . . . . . . . . . . . . 7 4.2. Body Processing . . . . . > . . . . . . . . . . . . . . . . 8 4.3. UAS Behavior . . . . . . . . . . . > . . . . . . . . . . . . 9 5. Guidelines to Authors of SIP Extensions . . > . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . > . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . > . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. > Informational References . . . . . . . . . . . . . . . . . 12 Author's > Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual > Property and Copyright Statements . . . . . . . . . . 13 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Camarillo Expires March 1, 2008 [Page 2] > Internet-Draft Message Body Handling in SIP August 2007 > > > 1. Introduction > > SIP [RFC3261] messages consist of an initial line (request line in requests > and status line in responses), a set of header fields, and an optional > message body. The message body is described using header fields such as > Content-Disposition, Content-Encoding, and Content- Type, which provide > information on its contents. This last sentence implies that you can have a body without MIME, although MIME defines Content-* fields. So SIP uses MIME-like Content-* fields, without a MIME body? > The message body of a SIP message can be divided into various body parts. > Multipart message bodies are encoded using the MIME (Multipurpose Internet > Mail Extensions) [RFC2045] format. Body parts are also described using > header fields such as Content-Disposition, Content-Encoding, and > Content-Type, which provide information on the contents of a particular > body part. > > Section 3 discusses issues related to the handling of multipart message > bodies in SIP. Section 4 discusses issues related to the disposition of > message bodies and body parts in SIP. > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 3. Multipart Message Bodies > > [RFC3261] did not mandate support for multipart message bodies in MIME > format [RFC2046]. However, since [RFC3261] was written, many SIP > extensions rely on them. Therefore, this specification updates [RFC3261]'s > recommendation regarding support for multipart MIME bodies. I think it does not "update" that specification, so much as to assert a profile of constraints on it. In other words, some of this document is a kind of Applicability Statement (which might constitute a 4th activity... If, in fact, this is a true update to the core SIP specification, please cite what parts of the original specification are being changed. It would also help to have a technical summary of the changes being made. > It is expected that most SIP UAs will implement extensions that require > them to generate 'multipart/mixed' MIME bodies. An example Stylistic point: Specifications which assert "it is expected that" are usually wrong. They are predicting the future, usually without need. Specifications should specify. Predicting the future is distracting. What I believe is sufficient is merely to state "In order to support extensions that require SIP UAs to generate..." > of such an extension would be the inclusion of location information in an > INVITE request. Such an INVITE request would use the 'multipart/mixed' > MIME type to carry two body parts: a session description and a location > object. An example of an existing extension that uses 'multipart/mixed' to > send a session description and a legacy-signalling object is defined in > [RFC3204]. This seems to scream for use of /related rather than /mixed. > Another MIME type a number of SIP UAs will need to generate is "will need to generate"? Is this normative or merely predictive? If the former, please write it that way. If the latter, the language along the lines of "might generate". d/) > 'multipart/alternative'. Each body part within a 'multipart/ alternative' > carries an alternative version of the same information. The body parts are > ordered so that the last one is the richest > > > > Camarillo Expires March 1, 2008 [Page 3] > Internet-Draft Message Body Handling in SIP August 2007 > > > representation of the information. This way, the recipient of a > 'multipart/alternative' body chooses the last body part it understands. > > Note that within a body part encoded in a given format (i.e., of a given > content type), there may be optional elements that may provide richer > information to the recipient in case the recipient supports them. For > example, in SDP (Session Description Protocol) [RFC4566], those optional > elements are encoded in 'a' lines. These types of optional elements are > internal to a body part and are not visible at the MIME level. That is, a > body part is understood if the recipient understands its content type, > regardless of whether or not the body part's optional elements are > understood. > > Note as well that each part of a 'multipart/alternative' body represents > the same data, but the mapping between any two parts is not necessarily > without information loss. For example, information may be lost when > translating 'text/html' to 'text/ plain'. > > It is expected that the transition from SDP to new session description > protocols is implemented using 'multipart/alternative' CHANGE: --> The transition from SDP to new... could be implemented using... > bodies. SIP messages (e.g., INVITE requests) would carry a > 'multipart/alternative' body with two body parts: a session description > written in SDP and a session description written in a newer session > description format. Legacy recipient UAs would use the session description > written in SDP. New recipient UAs would use the one written in the newer > format. > > A number of SIP UAs will also need to generate nested MIME bodies. Using > the extensions in the previous examples, a UA that supported a new session > description format and that needed to include a location object in an > INVITE request would include a 'multipart/mixed' body with two body parts: > a location object and a 'multipart/alternative'. The > 'multipart/alternative' body part would, in turn, have two body parts: a > session description written in SDP and a session description written in the > newer session description format. > > 3.1. General Considerations I believe that "Considerations" text usually does not include normative specification. > For all MIME-based extensions to work, the recipient needs to be able to > decode the multipart bodies. Therefore, SIP UAs MUST be able to parse > 'multipart' MIME bodies, including nested body parts. In particular, UAs > MUST support the 'multipart/mixed' and 'multipart/ alternative' MIME types. > Note that, by default, unknown 'multipart' subtypes are treated as > 'multipart/mixed'. > > > > > Camarillo Expires March 1, 2008 [Page 4] > Internet-Draft Message Body Handling in SIP August 2007 > > > Note that SIP extensions may also include 'multipart' MIME bodies in > responses. That is why both UACs and UASs need to support 'multipart' > bodies. > > 3.2. Body Generation > > UAs should avoid unnecessarily nesting body parts. However, Why should they avoid this? What are the criteria that define necessity? Absent explanatory background and very concrete specification of conditions that are acceptable or unacceptable, this kind of text is not very helpful. > [RFC2046] states that a 'multipart' media type with a single body part is > useful in some circumstances (e.g., for sending non-text media types). In > any case, UAs SHOULD NOT nest one 'multipart/mixed' within another unless > there is a need to reference the nested one (i.e., using the Content ID of > the nested body part). Additionally, UAs SHOULD NOT nest one > 'multipart/alternative' within another. > > All the body parts within a 'multipart/alternative' have the same > disposition type (see Section 4.1). Some disposition types require that > all the body parts of a 'multipart/alternative' body have different content > types. In particular, for the 'session' and 'early-session' [RFC3959] > disposition types, UAs MUST NOT place more than one body part with a given > content type in a 'multipart/ alternative' body. That is, for 'session' > and 'early-session', no body part within a 'multipart/alternative' can have > the same content type as another body part within the same > 'multipart/alternative'. So it is illegal to have two text/plain with different parameters? This question applies to some other content types, also, where differing parameters can specify significantly different actual content (such as pictures with different resolution.) This constraint seems excessive. > As stated earlier, the mapping between two body parts within a > 'multipart/alternative' body may imply information loss. [RFC2046] > recommends that each part should have a different Content-ID value in the > case where the information content of the two parts is not identical. > > A body part can only reference another body part if both are within the > same 'multipart/related' wrapper. Therefore, UAs MUST ensure that any > given body part only references body parts within its 'multipart/related' > wrapper. The "can" implies that only this situation is possible. If only that situation is possible, then UAs do not need to ensure it, so the normative stricture does not seem to be needed. If the 'can' is really meant to be a MUST, then we have two normative sentences in the paragraph and they appear to be saying the same thing. > UAs MUST use the binary transfer encoding for binary payloads in SIP. > > 3.3. UAS Behavior > > Section 3.1 mandates that all UAs support 'multipart' bodies. However, if a > particular UAS does not support 'multipart' bodies and receives one, the > UAS SHOULD return a 415 (Unsupported Media Type) response. Unless I am missing something quite basic, the above normative sentence defeats the earlier normative text that mandate support for multipart. This is a pure conflict. Either support is mandatory or it is not. If it is mandatory, then the actions of a UA that does not support multipart are out of scope. If it is not mandatory, then the earlier MUST needs to be changed to SHOULD. However this sort of basic, apparent contradtiction in a specification often signals some deeper ambiguities or conflicts within the working group. The document then suffers a pattern of problems. > Note that it is essential that UASs without MIME support are at least able > to return an error response when receiving a 'multipart' body. Not being > able to signal this type of error The above is icing on the confusion cake. Now it is saying that non-supporting UAs must support multiparts partially. This is yet a third type of normative statement about support, conflicting with the other two (IMO), > could cause serious interoperability problems. Legacy UASs > > > > Camarillo Expires March 1, 2008 [Page 5] > Internet-Draft Message Body Handling in SIP August 2007 > > > without MIME support that, for some reason, cannot be immediately upgraded > to support MIME, should at least be upgraded to be able to report this > error. > > As specified in [RFC3261], UASs that cannot decrypt a message body or a > body part can use the 493 (Undecipherable) response to report the error. > > > 4. Message-body and Body-part Disposition > > The Content-Disposition header field, defined in [RFC2183] and extended by > [RFC3261], describes how to handle a SIP message's body or an individual > body part. Examples of disposition types used in SIP in the > Content-Disposition header field are 'session' and 'render'. > > [RFC3204] and [RFC3459] define the 'handling' parameter for the > Content-Disposition header field. This parameter describes how a UAS > should react if it receives a message body whose content type or > disposition type it does not understand. If the parameter has the value > 'optional', the UAS ignores the message body; if it has the value > 'required', the UAS returns a 415 (Unsupported Media Type) response. The > default value for the 'handling' parameter is 'required'. > > [RFC3204] identifies two situations where a UAS (User Agent Server) needs > to reject a request with a body part whose handling is required: > > 1. if it has an unknown content type. 2. if it has an unknown disposition > type. > > If the UAS (User Agent Server) did not understand the content type of the > body part, it can add an Accept header field to its 415 (Unsupported Media > Type) response listing the content types that the UAS does understand. > Nevertheless, there is no mechanism for a UAS that does not understand the > disposition type of a body part to inform the UAC (User Agent Client) > about which disposition type was not understood or about the disposition > types that are understood by the UAS. > > The reason for not having such a mechanism is that disposition types are > typically supported within a context. Outside that context, a UA (User > Agent) may not support the disposition type. For example, a UA may support > the 'session' disposition type for body parts in INVITE and UPDATE > requests and their responses. However, the same UA would not support the > 'session' disposition type in MESSAGE requests. > > > > Camarillo Expires March 1, 2008 [Page 6] > Internet-Draft Message Body Handling in SIP August 2007 > > > In another example, a UA may support the 'render' disposition type for > 'text/plain' and 'text/html' body parts in MESSAGE requests. Additionally, > the UA may support the 'session' disposition type for 'application/sdp' > body parts in INVITE and UPDATE requests and their responses. However, the > UA may not support the 'render' disposition type for 'application/sdp' > body parts in MESSAGE requests, even if, in different contexts, the UA > supported all the 'render' disposition type, the 'application/sdp' content > type, and the MESSAGE method. > > A given context is generally (but not necessarily) defined by a method, a > disposition type, and a content type. Support for a specific context is > usually defined within an extension. For example, the extension for > instant messaging in SIP [RFC3428] mandates support for the MESSAGE method, > the 'render' disposition type, and the 'text/plain' content type. > > Note that, effectively, content types are also supported within a context. > Therefore, the use of the Accept header field in a 415 (Unsupported Media > Type) response is not enough to describe in which contexts a particular > content type is supported. > > Therefore, support for a particular disposition type within a given context > is typically signalled by the use of a particular method or an option-tag > in a Supported or a Require header field. When support for a particular > disposition type within a context is mandated, support for a default > content type is also mandated (e.g., a UA that supports the 'session' > disposition type in an INVITE request needs to support the > 'application/sdp' content type). > > Content-ID URLs (Uniform Resource Locators) are another tool to describe > how a body part should be handled. Some extensions use a Content-ID URL > [RFC2392], which can appear in a header field or within a body part (e.g., > in an SDP attribute), that points to a body part. The way to handle that > body part is defined by the field the Content-ID URL appears in and by the > disposition type of the body part. For example, the extension to refer to > multiple resources in SIP [I-D.ietf-sip-multiple-refer] places a > Content-ID URL in a Refer-To header field. Such a Content-ID URL points to > a body part whose disposition type is supposed to be 'recipient-list'. In > another example, the extension for file transfer in SDP > [I-D.ietf-mmusic-file-transfer-mech] places a Content-ID URL in a > 'file-icon' SDP attribute. This Content-ID URL points to a body part whose > disposition type is supposed to be 'icon'. > > 4.1. Body Generation > > As stated earlier, the 'handling' Content-Disposition parameter can take > two values: 'required' or 'optional'. While it is typically > > > > Camarillo Expires March 1, 2008 [Page 7] > Internet-Draft Message Body Handling in SIP August 2007 > > > easy for a UA to decide which type of handling an individual body part > requires, setting the 'handing' parameter of 'multipart' bodies requires > extra considerations. > > If at least one of the body parts within a 'multipart/mixed' body has a > 'handling' value of 'required', the UA MUST set the 'handling' parameter of > the 'multipart/mixed' body to 'required'. If all the body parts within a > 'multipart/mixed' body have a 'handling' value of 'optional', the UA MUST > set the 'handling' parameter of the 'multipart/mixed' body to 'optional'. > > The 'handling' parameter is a Content-Disposition parameter. Therefore, in > order to set this parameter, it is necessary to provide the > 'multipart/mixed' body with a disposition type. Per [RFC3261], the default > disposition type for 'application/sdp' is 'session' and for other bodies > is 'render'. UAs SHOULD assign 'multipart/mixed' bodies a disposition type > of 'render'. > > Note that the fact that 'multipart/mixed' bodies have a disposition type of > 'render' does not imply that they will be rendered to the user. The way > the body parts within the 'multipart/mixed' are handled depends on the > disposition types of the individual body parts. The actual disposition > type of the whole 'multipart/mixed' is irrelevant. The 'render' > disposition type has been chosen for 'multipart/mixed' bodies simply > because it is the default disposition type in SIP. > > If the handling of a 'multipart/alternative' body is required, the UA MUST > set the 'handling' parameter of the 'multipart/alternative' body and to > the last body part within the 'multipart/alternative' to 'required'. > Additionally, the UA MUST set the 'handling' parameter of all body parts > within the 'multipart/alternative' except the last one to 'optional'. The > UA MUST use the same disposition type for the 'multipart/alternative' body > and all its body parts. I am confused by the above paragraph, enough to be unclear how to describe the confusion. So I'll simply ask that someone other than the author word-smith it very carefully, to make sure that it says only and exactly the normative actions that are intended. The reason for suggesting it be a different person is simply to get a different language processing brain to work on the text. I find this often helps clarify my own authored text quite a bit. > 4.2. Body Processing > > In order to process a message body or a body part, a UA needs to know > whether a SIP header field or another body part contains a reference I do not understand why. And I guess this means that there can be no processing of any body part until the entire body is scan for references to it? Seem onerous, but maybe not that unusual for MIME. > to it (e.g., a Content-ID URL pointing to it). If the body part is not > referenced in any way (e.g., there are no header fields or other body parts > with a Content-ID URL pointing to it), the UA processes the body part as > indicated by its disposition type and the context in which the body part > was received. > > If the SIP message contains a reference to the body part, the UA processes > the body part according to the reference and the disposition type of the > body part. If the SIP message contains more So, a reference completely overrides the processing that is done "local" to the actual body part? Or do you mean that the body-part might be processed repeatedly, once for each reference (and possibly once at its actual occurrence?) If it is not processed at its actual occurrence, why not? Hmmm. Perhaps this is a characteristic of /related: Processing always flows from "entry point" body part and not of the other, related body parts has an utility of its own. This is in marked contrast with /mixed, where each body part is independent. > > > Camarillo Expires March 1, 2008 [Page 8] > Internet-Draft Message Body Handling in SIP August 2007 > > > than one reference to the body part (e.g., two header fields contain > Content-ID URLs pointing to the body part), the UA processes the body part > as many times as references there are. And, indeed, this text, here, seems to support the interpretation I am suggesting. > A UA looking for references to a body part starts by parsing the SIP > message's header fields. Additionally, if the body part is within a > 'multipart/related' [RFC2387] wrapper, the body parts within the > 'multipart/related' wrapper may reference each other. Therefore, the UA > processes the body parts in the 'multipart/related', starting with its > 'root', looking for references to the body part. What is it about the above that is "clarifying"? > Note that, per [RFC2387], a UA processing a 'multipart/related' body > processes it as a compound object ignoring the disposition types of the > body parts within it. This paragraph appears to be contradicting the one before it. > Following the rules in [RFC3204], if a UA does not understand a body part > whose handling is optional, it ignores it. > > Note that the content indirection mechanism in SIP [RFC4483] allows UAs to > point to external bodies. Therefore, a UA receiving a SIP message that > uses content indirection may need to fetch a body part (e.g., using HTTP > [RFC2616]) in order to process it. > > 4.3. UAS Behavior > > If a UAS cannot process a request because, in the given context, it does > not support the content type or the disposition type of a body part whose > handling is required, the UAS SHOULD return a 415 (Unsupported Media Type) > response even if the UAS supported the content type, the disposition type, > or both in a different context. Why isn't it a MUST rather than a SHOULD??? > Consequently, it is possible to receive a 415 (Unsupported Media Type) > response with an Accept header field containing all the content types used > in the request. > > If a UAS receives a request with a body part whose disposition type is not > compatible with the way the body part should be handled according to other > parts of the SIP message (e.g., a Refer-To header field with a Content-ID > URL pointing to a body part whose disposition type is 'session'), the UAS > SHOULD return a 415 (Unsupported Media Type) response. > > > 5. Guidelines to Authors of SIP Extensions > > These guidelines are intended for authors of SIP extensions that involve, > in some way, message bodies or body parts. > > > > > Camarillo Expires March 1, 2008 [Page 9] > Internet-Draft Message Body Handling in SIP August 2007 > > > This specification mandates support for 'multipart/mixed' and mandates. mumble. hmmm... > 'multipart/alternative' and describes how to handle 'multipart/ related' > [RFC2387] bodies. At present, there are no SIP extensions that use > different 'multipart' subtypes such as parallel [RFC2046] or digest > [RFC2046]. If such extensions were to be defined in the future, their > authors would need to make sure (e.g., by using an option-tag or by other > means) that entities receiving those 'multipart' subtypes were able to > process them. As stated earlier, UAs treat unknown 'multipart' subtypes as > 'multipart/mixed'. > > Body parts within a 'multipart/related' wrapper can reference each other. > Per [RFC2387], a UA processing a 'multipart/related' body processes it as a > compound object ignoring the disposition types of the body parts within > it. However, UAs that do not understand 'multipart/related' will treat it > as 'multipart/mixed'. These UAs will not be able to process the references > among the body parts and will process the body parts according to their > disposition type. > > When a SIP UA receives a header field or an optional body part it does not > understand, the UA ignores it. A header field or a body part carrying a > reference to another body part (e.g., a Content-ID URL) can influence the > way that body part is handled. If a header If this pertains to the earlier discussion about processing a reference, then there is no "can"; there is only "will". If this sentence is intended to convey some other implication, then I do not understand what it is. > field or a body part carrying a reference to a body part is not understood > and, thus, ignored by its recipient, the body part could be handled in an > unintended way. Therefore, authors of SIP "could"? If the body part is not understood then its handling is well-defined. While the generating of the part certainly did not "intend" that handling, they have to assume that a given recipient might not be able to process it and existing specification text says how to handle it. So, I am guessing that the text needs to say something like "In order to ensure that referenced body parts are processed properly, authors of SIP extensions..." > extensions that involve references to body parts need to make sure (e.g., > by using an option-tag or by other means) that entities processing those > extensions do not behave in unintended ways. I do not see how the above 4 paragraphs in this section offer 'guidelines' for extensions. > Additionally, authors of such extensions need to specify the acceptable > disposition types of the referenced body part and a default, mandatory to > support, content type per disposition type. > > As stated earlier, SIP extensions may also include 'multipart' MIME bodies > in responses. However, UACs receiving a response cannot CHANGE: ...bodies in responses. Hence, a response can be extremely complex and the client receiving the response might not be able to process the response correctly. Because UACs receiving a response cannot...requests), authors of SIP... > report errors to the UAS that generated the response (i.e., error responses > can only be generated for requests). Therefore, authors of SIP extensions > need to make sure that requests clearly indicate (e.g., by using an > option-tag or by other means) the capabilities of the UAC so that UASs can > decide what to include in their responses. > > > 6. Security Considerations > > TBD. > > > > > > > Camarillo Expires March 1, 2008 [Page 10] > Internet-Draft Message Body Handling in SIP August 2007 > > > 7. Acknowledgements > > The ideas in this document were discussed with Paul Kyzivat. Christer > Holmberg, Francois Audet, and Dan Wing provided comments on this document. > > > 8. IANA Considerations > > This document does not contain any IANA actions. > > > 9. References > > 9.1. Normative References > > [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail > Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, > November 1996. > > [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail > Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating > Presentation Information in Internet Messages: The Content-Disposition > Header Field", RFC 2183, August 1997. > > [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC > 2387, August 1998. > > [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource > Locators", RFC 2392, August 1998. > > [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., > Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", > RFC 3204, December 2001. > > [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., > Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session > Initiation Protocol", RFC 3261, June 2002. > > [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail > Extensions (MIME) Parameter", RFC 3459, January 2003. > > > > Camarillo Expires March 1, 2008 [Page 11] > Internet-Draft Message Body Handling in SIP August 2007 > > > [RFC3959] Camarillo, G., "The Early Session Disposition Type for the > Session Initiation Protocol (SIP)", RFC 3959, December 2004. > > [RFC4483] Burger, E., "A Mechanism for Content Indirection in Session > Initiation Protocol (SIP) Messages", RFC 4483, May 2006. > > 9.2. Informational References > > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., > Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", > RFC 2616, June 1999. > > [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and > D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant > Messaging", RFC 3428, December 2002. > > [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session > Description Protocol", RFC 4566, July 2006. > > [I-D.ietf-sip-multiple-refer] Camarillo, G., "Referring to Multiple > Resources in the Session Initiation Protocol (SIP)", > draft-ietf-sip-multiple-refer-01 (work in progress), January 2007. > > [I-D.ietf-mmusic-file-transfer-mech] Garcia-Martin, M., "A Session > Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", > draft-ietf-mmusic-file-transfer-mech-03 (work in progress), June 2007. > > > Author's Address > > Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland > > Email: Gonzalo.Camarillo@ericsson.com > > > > > > > > > Camarillo Expires March 1, 2008 [Page 12] > Internet-Draft Message Body Handling in SIP August 2007 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2007). > > This document is subject to the rights, licenses and restrictions contained > in BCP 78, and except as set forth therein, the authors retain all their > rights. > > This document and the information contained herein are provided on an "AS > IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS > SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE > INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES > OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in this > document or the extent to which any license under such rights might or > might not be available; nor does it represent that it has made any > independent effort to identify any such rights. Information on the > procedures with respect to rights in RFC documents can be found in BCP 78 > and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any assurances > of licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such proprietary > rights by implementers or users of this specification can be obtained from > the IETF on-line IPR repository at http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary rights > that may cover technology that may be required to implement this standard. > Please address the information to the IETF at ietf-ipr@ietf.org. > > > Acknowledgment > > Funding for the RFC Editor function is provided by the IETF Administrative > Support Activity (IASA). > > > > > > Camarillo Expires March 1, 2008 [Page 13] -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review From apps-review-bounces@ietf.org Fri Nov 16 09:36:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2JV-0007HI-Ai; Fri, 16 Nov 2007 09:36:57 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IshZ8-0007Jx-K5 for apps-review-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:27:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshZ2-0007IM-Pu for apps-review@ietf.org; Thu, 15 Nov 2007 11:27:36 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshYv-0003kn-O2 for apps-review@ietf.org; Thu, 15 Nov 2007 11:27:36 -0500 Received: from [192.168.2.3] ([72.54.167.34]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lAFGQrvX029518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2007 08:26:55 -0800 Message-ID: <473C73C3.3070001@bbiw.net> Date: Thu, 15 Nov 2007 10:28:51 -0600 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gonzalo.Camarillo@ericsson.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 507ad05d8e517f8285c14ade4dc3acf0 X-Mailman-Approved-At: Fri, 16 Nov 2007 09:36:56 -0500 Cc: apps-review@ietf.org Subject: [APPS-REVIEW] Review of draft-ietf-sip-body-handling-00.txt X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org This is a review of draft-ietf-sip-body-handling-00.txt. The document states that its goal is to 'clarify' the handling of message bodies in SIP and to mandate details of MIME "encoding" of bodies. On their face, both of these are worthy tasks, with a history of having been useful when provided for other protocols. The current draft seems to mix a number of activities: 1. Basic tutorial coverage of material from other specifications. Sometimes this is quite basic. Its inclusion raises the question of what required background is expected of readers? If very basic material is needed, why is there relatively little of it? It might help for the document to make an explicit statement about the background that is expected of the reader, and the types of simple pedagogy that are included (and why). That is, where is the reader expected to start from and where will this document's purely instructional material take the reader to? 2. Clarification in the sense of pointing out key aspects of other specifications that are relevant to the handling of SIP message bodies, possibly including statements about non-obvious implications. In effect, this type of material is also instructional, but not about the basics. Rather than essentially regurgitating or restating existing material, as Activity #1 does, this type of material, documents implications that are not obvious and well might not have been written before. (This is exactly the added insight that experience provides, of course, and is what motivates documents like this.) 3. Assertion of normative specification details. These might fix problems, expand functionality, or adapt the functionality to the idiosyncrasies of the SIP environment. All 3 activities can provide significant assistance. I suppose that the document seeks to do a job for SIP that is similar to what RFC1123/RFC1122 did for a variety of protocols in the late 1980s? General Comments ================ The document mixes its 3 activities, which I found confusing. Sometimes there seems to be normative intent, without normative language and sometimes there is normative language (should or may) without normative intent. When there appears to be normative intent, I assume that the document is trying to build upon details from other, existing specifications, but the document does not cite the specific sections of text that it is modifying or building upon. Sometimes I was not sure which activity a given segment of text was attempting to perform. I suspect the document will benefit from some re-organization, according the the activity being performed. A sequence of basic pedagogy, followed by new insights and implications, followed by refining or modifying normative specification could make things much clearer to the reader. In general, it appears that SIP has taken MIME constructs and profiled them into an incompatible, overlap with email MIME, just as Web MIME did, but possibly more dramatically. To the extent that SIP's use of MIME is incompatible with nearly 15 years of using MIME for email (and the web) the document should probably make explicit statements about the differences. If these are already stated elsewhere, the document should cite the relevant text. Offhand, I'd guess it would help to explain the reasons for the incompatibilities, so that readers do not assume that the choices were arbitrary. (This is a version of explaining implications that is not in the current document but that I think fits into its goal nicely.) On the open matter of constraints about when MIME references are allowed, I do not have a resolution to recommend. I think it needs to be determined by a clear statement of the requirements/constraints that are causing the issue to be an issue. The thread I read covered some of this, but I did not see working group consensus on a summary. That is, if you are going to change from the pre-existing use of MIME references, there are processing concerns that prompt the change. They should be documented and maybe rank-ordered. In effect, you need to say how SIP is providing a different environment in which references are being used and, therefore, what constraints this different environment is imposing. Detailed Comments ================= I'll apologize for choosing to include the entire document. I decided that this makes it much easier to see the context of the comments. In addition, comments occur regularly enough so that trying to cut out bits would not shorten things much... > SIP Working Group G. Camarillo > Internet-Draft Ericsson > Expires: March 1, 2008 August 29, 2007 > > > Message Body Handling in the Session Initiation Protocol (SIP) > draft-ietf-sip-body-handling-00.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware have been > or will be disclosed, and any of which he or she becomes aware will be > disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. Note that other groups > may also distribute working documents as Internet- Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months and > may be updated, replaced, or obsoleted by other documents at any time. It > is inappropriate to use Internet-Drafts as reference material or to cite > them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on March 1, 2008. > > Copyright Notice > > Copyright (C) The IETF Trust (2007). > > Abstract > > This document clarifies how message bodies are handled in SIP. "Clarifies" implies states implications. > Additionally, it discusses to which degree SIP user agents need to support > MIME (Multipurpose Internet Mail Extensions)-encoding of body parts. CHANGE last sentence: --> Additionally, it specifies SIP user agent support for MIME in message bodies. (More direct statement. This is normative. /d) > > > > > > > > Camarillo Expires March 1, 2008 [Page 1] > Internet-Draft Message Body Handling in SIP August 2007 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. > Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. > Multipart Message Bodies . . . . . . . . . . . . . . . . . . . 3 3.1. > General Considerations . . . . . . . . . . . . . . . . . . 4 3.2. Body > Generation . . . . . . . . . . . . . . . . . . . . . 5 3.3. UAS Behavior > . . . . . . . . . . . . . . . . . . . . . . . 5 4. Message-body and > Body-part Disposition . . . . . . . . . . . . 6 4.1. Body Generation . . > . . . . . . . . . . . . . . . . . . . 7 4.2. Body Processing . . . . . > . . . . . . . . . . . . . . . . 8 4.3. UAS Behavior . . . . . . . . . . . > . . . . . . . . . . . . 9 5. Guidelines to Authors of SIP Extensions . . > . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . > . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . > . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. > Informational References . . . . . . . . . . . . . . . . . 12 Author's > Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual > Property and Copyright Statements . . . . . . . . . . 13 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Camarillo Expires March 1, 2008 [Page 2] > Internet-Draft Message Body Handling in SIP August 2007 > > > 1. Introduction > > SIP [RFC3261] messages consist of an initial line (request line in requests > and status line in responses), a set of header fields, and an optional > message body. The message body is described using header fields such as > Content-Disposition, Content-Encoding, and Content- Type, which provide > information on its contents. This last sentence implies that you can have a body without MIME, although MIME defines Content-* fields. So SIP uses MIME-like Content-* fields, without a MIME body? > The message body of a SIP message can be divided into various body parts. > Multipart message bodies are encoded using the MIME (Multipurpose Internet > Mail Extensions) [RFC2045] format. Body parts are also described using > header fields such as Content-Disposition, Content-Encoding, and > Content-Type, which provide information on the contents of a particular > body part. > > Section 3 discusses issues related to the handling of multipart message > bodies in SIP. Section 4 discusses issues related to the disposition of > message bodies and body parts in SIP. > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 3. Multipart Message Bodies > > [RFC3261] did not mandate support for multipart message bodies in MIME > format [RFC2046]. However, since [RFC3261] was written, many SIP > extensions rely on them. Therefore, this specification updates [RFC3261]'s > recommendation regarding support for multipart MIME bodies. I think it does not "update" that specification, so much as to assert a profile of constraints on it. In other words, some of this document is a kind of Applicability Statement (which might constitute a 4th activity... If, in fact, this is a true update to the core SIP specification, please cite what parts of the original specification are being changed. It would also help to have a technical summary of the changes being made. > It is expected that most SIP UAs will implement extensions that require > them to generate 'multipart/mixed' MIME bodies. An example Stylistic point: Specifications which assert "it is expected that" are usually wrong. They are predicting the future, usually without need. Specifications should specify. Predicting the future is distracting. What I believe is sufficient is merely to state "In order to support extensions that require SIP UAs to generate..." > of such an extension would be the inclusion of location information in an > INVITE request. Such an INVITE request would use the 'multipart/mixed' > MIME type to carry two body parts: a session description and a location > object. An example of an existing extension that uses 'multipart/mixed' to > send a session description and a legacy-signalling object is defined in > [RFC3204]. This seems to scream for use of /related rather than /mixed. > Another MIME type a number of SIP UAs will need to generate is "will need to generate"? Is this normative or merely predictive? If the former, please write it that way. If the latter, the language along the lines of "might generate". d/) > 'multipart/alternative'. Each body part within a 'multipart/ alternative' > carries an alternative version of the same information. The body parts are > ordered so that the last one is the richest > > > > Camarillo Expires March 1, 2008 [Page 3] > Internet-Draft Message Body Handling in SIP August 2007 > > > representation of the information. This way, the recipient of a > 'multipart/alternative' body chooses the last body part it understands. > > Note that within a body part encoded in a given format (i.e., of a given > content type), there may be optional elements that may provide richer > information to the recipient in case the recipient supports them. For > example, in SDP (Session Description Protocol) [RFC4566], those optional > elements are encoded in 'a' lines. These types of optional elements are > internal to a body part and are not visible at the MIME level. That is, a > body part is understood if the recipient understands its content type, > regardless of whether or not the body part's optional elements are > understood. > > Note as well that each part of a 'multipart/alternative' body represents > the same data, but the mapping between any two parts is not necessarily > without information loss. For example, information may be lost when > translating 'text/html' to 'text/ plain'. > > It is expected that the transition from SDP to new session description > protocols is implemented using 'multipart/alternative' CHANGE: --> The transition from SDP to new... could be implemented using... > bodies. SIP messages (e.g., INVITE requests) would carry a > 'multipart/alternative' body with two body parts: a session description > written in SDP and a session description written in a newer session > description format. Legacy recipient UAs would use the session description > written in SDP. New recipient UAs would use the one written in the newer > format. > > A number of SIP UAs will also need to generate nested MIME bodies. Using > the extensions in the previous examples, a UA that supported a new session > description format and that needed to include a location object in an > INVITE request would include a 'multipart/mixed' body with two body parts: > a location object and a 'multipart/alternative'. The > 'multipart/alternative' body part would, in turn, have two body parts: a > session description written in SDP and a session description written in the > newer session description format. > > 3.1. General Considerations I believe that "Considerations" text usually does not include normative specification. > For all MIME-based extensions to work, the recipient needs to be able to > decode the multipart bodies. Therefore, SIP UAs MUST be able to parse > 'multipart' MIME bodies, including nested body parts. In particular, UAs > MUST support the 'multipart/mixed' and 'multipart/ alternative' MIME types. > Note that, by default, unknown 'multipart' subtypes are treated as > 'multipart/mixed'. > > > > > Camarillo Expires March 1, 2008 [Page 4] > Internet-Draft Message Body Handling in SIP August 2007 > > > Note that SIP extensions may also include 'multipart' MIME bodies in > responses. That is why both UACs and UASs need to support 'multipart' > bodies. > > 3.2. Body Generation > > UAs should avoid unnecessarily nesting body parts. However, Why should they avoid this? What are the criteria that define necessity? Absent explanatory background and very concrete specification of conditions that are acceptable or unacceptable, this kind of text is not very helpful. > [RFC2046] states that a 'multipart' media type with a single body part is > useful in some circumstances (e.g., for sending non-text media types). In > any case, UAs SHOULD NOT nest one 'multipart/mixed' within another unless > there is a need to reference the nested one (i.e., using the Content ID of > the nested body part). Additionally, UAs SHOULD NOT nest one > 'multipart/alternative' within another. > > All the body parts within a 'multipart/alternative' have the same > disposition type (see Section 4.1). Some disposition types require that > all the body parts of a 'multipart/alternative' body have different content > types. In particular, for the 'session' and 'early-session' [RFC3959] > disposition types, UAs MUST NOT place more than one body part with a given > content type in a 'multipart/ alternative' body. That is, for 'session' > and 'early-session', no body part within a 'multipart/alternative' can have > the same content type as another body part within the same > 'multipart/alternative'. So it is illegal to have two text/plain with different parameters? This question applies to some other content types, also, where differing parameters can specify significantly different actual content (such as pictures with different resolution.) This constraint seems excessive. > As stated earlier, the mapping between two body parts within a > 'multipart/alternative' body may imply information loss. [RFC2046] > recommends that each part should have a different Content-ID value in the > case where the information content of the two parts is not identical. > > A body part can only reference another body part if both are within the > same 'multipart/related' wrapper. Therefore, UAs MUST ensure that any > given body part only references body parts within its 'multipart/related' > wrapper. The "can" implies that only this situation is possible. If only that situation is possible, then UAs do not need to ensure it, so the normative stricture does not seem to be needed. If the 'can' is really meant to be a MUST, then we have two normative sentences in the paragraph and they appear to be saying the same thing. > UAs MUST use the binary transfer encoding for binary payloads in SIP. > > 3.3. UAS Behavior > > Section 3.1 mandates that all UAs support 'multipart' bodies. However, if a > particular UAS does not support 'multipart' bodies and receives one, the > UAS SHOULD return a 415 (Unsupported Media Type) response. Unless I am missing something quite basic, the above normative sentence defeats the earlier normative text that mandate support for multipart. This is a pure conflict. Either support is mandatory or it is not. If it is mandatory, then the actions of a UA that does not support multipart are out of scope. If it is not mandatory, then the earlier MUST needs to be changed to SHOULD. However this sort of basic, apparent contradtiction in a specification often signals some deeper ambiguities or conflicts within the working group. The document then suffers a pattern of problems. > Note that it is essential that UASs without MIME support are at least able > to return an error response when receiving a 'multipart' body. Not being > able to signal this type of error The above is icing on the confusion cake. Now it is saying that non-supporting UAs must support multiparts partially. This is yet a third type of normative statement about support, conflicting with the other two (IMO), > could cause serious interoperability problems. Legacy UASs > > > > Camarillo Expires March 1, 2008 [Page 5] > Internet-Draft Message Body Handling in SIP August 2007 > > > without MIME support that, for some reason, cannot be immediately upgraded > to support MIME, should at least be upgraded to be able to report this > error. > > As specified in [RFC3261], UASs that cannot decrypt a message body or a > body part can use the 493 (Undecipherable) response to report the error. > > > 4. Message-body and Body-part Disposition > > The Content-Disposition header field, defined in [RFC2183] and extended by > [RFC3261], describes how to handle a SIP message's body or an individual > body part. Examples of disposition types used in SIP in the > Content-Disposition header field are 'session' and 'render'. > > [RFC3204] and [RFC3459] define the 'handling' parameter for the > Content-Disposition header field. This parameter describes how a UAS > should react if it receives a message body whose content type or > disposition type it does not understand. If the parameter has the value > 'optional', the UAS ignores the message body; if it has the value > 'required', the UAS returns a 415 (Unsupported Media Type) response. The > default value for the 'handling' parameter is 'required'. > > [RFC3204] identifies two situations where a UAS (User Agent Server) needs > to reject a request with a body part whose handling is required: > > 1. if it has an unknown content type. 2. if it has an unknown disposition > type. > > If the UAS (User Agent Server) did not understand the content type of the > body part, it can add an Accept header field to its 415 (Unsupported Media > Type) response listing the content types that the UAS does understand. > Nevertheless, there is no mechanism for a UAS that does not understand the > disposition type of a body part to inform the UAC (User Agent Client) > about which disposition type was not understood or about the disposition > types that are understood by the UAS. > > The reason for not having such a mechanism is that disposition types are > typically supported within a context. Outside that context, a UA (User > Agent) may not support the disposition type. For example, a UA may support > the 'session' disposition type for body parts in INVITE and UPDATE > requests and their responses. However, the same UA would not support the > 'session' disposition type in MESSAGE requests. > > > > Camarillo Expires March 1, 2008 [Page 6] > Internet-Draft Message Body Handling in SIP August 2007 > > > In another example, a UA may support the 'render' disposition type for > 'text/plain' and 'text/html' body parts in MESSAGE requests. Additionally, > the UA may support the 'session' disposition type for 'application/sdp' > body parts in INVITE and UPDATE requests and their responses. However, the > UA may not support the 'render' disposition type for 'application/sdp' > body parts in MESSAGE requests, even if, in different contexts, the UA > supported all the 'render' disposition type, the 'application/sdp' content > type, and the MESSAGE method. > > A given context is generally (but not necessarily) defined by a method, a > disposition type, and a content type. Support for a specific context is > usually defined within an extension. For example, the extension for > instant messaging in SIP [RFC3428] mandates support for the MESSAGE method, > the 'render' disposition type, and the 'text/plain' content type. > > Note that, effectively, content types are also supported within a context. > Therefore, the use of the Accept header field in a 415 (Unsupported Media > Type) response is not enough to describe in which contexts a particular > content type is supported. > > Therefore, support for a particular disposition type within a given context > is typically signalled by the use of a particular method or an option-tag > in a Supported or a Require header field. When support for a particular > disposition type within a context is mandated, support for a default > content type is also mandated (e.g., a UA that supports the 'session' > disposition type in an INVITE request needs to support the > 'application/sdp' content type). > > Content-ID URLs (Uniform Resource Locators) are another tool to describe > how a body part should be handled. Some extensions use a Content-ID URL > [RFC2392], which can appear in a header field or within a body part (e.g., > in an SDP attribute), that points to a body part. The way to handle that > body part is defined by the field the Content-ID URL appears in and by the > disposition type of the body part. For example, the extension to refer to > multiple resources in SIP [I-D.ietf-sip-multiple-refer] places a > Content-ID URL in a Refer-To header field. Such a Content-ID URL points to > a body part whose disposition type is supposed to be 'recipient-list'. In > another example, the extension for file transfer in SDP > [I-D.ietf-mmusic-file-transfer-mech] places a Content-ID URL in a > 'file-icon' SDP attribute. This Content-ID URL points to a body part whose > disposition type is supposed to be 'icon'. > > 4.1. Body Generation > > As stated earlier, the 'handling' Content-Disposition parameter can take > two values: 'required' or 'optional'. While it is typically > > > > Camarillo Expires March 1, 2008 [Page 7] > Internet-Draft Message Body Handling in SIP August 2007 > > > easy for a UA to decide which type of handling an individual body part > requires, setting the 'handing' parameter of 'multipart' bodies requires > extra considerations. > > If at least one of the body parts within a 'multipart/mixed' body has a > 'handling' value of 'required', the UA MUST set the 'handling' parameter of > the 'multipart/mixed' body to 'required'. If all the body parts within a > 'multipart/mixed' body have a 'handling' value of 'optional', the UA MUST > set the 'handling' parameter of the 'multipart/mixed' body to 'optional'. > > The 'handling' parameter is a Content-Disposition parameter. Therefore, in > order to set this parameter, it is necessary to provide the > 'multipart/mixed' body with a disposition type. Per [RFC3261], the default > disposition type for 'application/sdp' is 'session' and for other bodies > is 'render'. UAs SHOULD assign 'multipart/mixed' bodies a disposition type > of 'render'. > > Note that the fact that 'multipart/mixed' bodies have a disposition type of > 'render' does not imply that they will be rendered to the user. The way > the body parts within the 'multipart/mixed' are handled depends on the > disposition types of the individual body parts. The actual disposition > type of the whole 'multipart/mixed' is irrelevant. The 'render' > disposition type has been chosen for 'multipart/mixed' bodies simply > because it is the default disposition type in SIP. > > If the handling of a 'multipart/alternative' body is required, the UA MUST > set the 'handling' parameter of the 'multipart/alternative' body and to > the last body part within the 'multipart/alternative' to 'required'. > Additionally, the UA MUST set the 'handling' parameter of all body parts > within the 'multipart/alternative' except the last one to 'optional'. The > UA MUST use the same disposition type for the 'multipart/alternative' body > and all its body parts. I am confused by the above paragraph, enough to be unclear how to describe the confusion. So I'll simply ask that someone other than the author word-smith it very carefully, to make sure that it says only and exactly the normative actions that are intended. The reason for suggesting it be a different person is simply to get a different language processing brain to work on the text. I find this often helps clarify my own authored text quite a bit. > 4.2. Body Processing > > In order to process a message body or a body part, a UA needs to know > whether a SIP header field or another body part contains a reference I do not understand why. And I guess this means that there can be no processing of any body part until the entire body is scan for references to it? Seem onerous, but maybe not that unusual for MIME. > to it (e.g., a Content-ID URL pointing to it). If the body part is not > referenced in any way (e.g., there are no header fields or other body parts > with a Content-ID URL pointing to it), the UA processes the body part as > indicated by its disposition type and the context in which the body part > was received. > > If the SIP message contains a reference to the body part, the UA processes > the body part according to the reference and the disposition type of the > body part. If the SIP message contains more So, a reference completely overrides the processing that is done "local" to the actual body part? Or do you mean that the body-part might be processed repeatedly, once for each reference (and possibly once at its actual occurrence?) If it is not processed at its actual occurrence, why not? Hmmm. Perhaps this is a characteristic of /related: Processing always flows from "entry point" body part and not of the other, related body parts has an utility of its own. This is in marked contrast with /mixed, where each body part is independent. > > > Camarillo Expires March 1, 2008 [Page 8] > Internet-Draft Message Body Handling in SIP August 2007 > > > than one reference to the body part (e.g., two header fields contain > Content-ID URLs pointing to the body part), the UA processes the body part > as many times as references there are. And, indeed, this text, here, seems to support the interpretation I am suggesting. > A UA looking for references to a body part starts by parsing the SIP > message's header fields. Additionally, if the body part is within a > 'multipart/related' [RFC2387] wrapper, the body parts within the > 'multipart/related' wrapper may reference each other. Therefore, the UA > processes the body parts in the 'multipart/related', starting with its > 'root', looking for references to the body part. What is it about the above that is "clarifying"? > Note that, per [RFC2387], a UA processing a 'multipart/related' body > processes it as a compound object ignoring the disposition types of the > body parts within it. This paragraph appears to be contradicting the one before it. > Following the rules in [RFC3204], if a UA does not understand a body part > whose handling is optional, it ignores it. > > Note that the content indirection mechanism in SIP [RFC4483] allows UAs to > point to external bodies. Therefore, a UA receiving a SIP message that > uses content indirection may need to fetch a body part (e.g., using HTTP > [RFC2616]) in order to process it. > > 4.3. UAS Behavior > > If a UAS cannot process a request because, in the given context, it does > not support the content type or the disposition type of a body part whose > handling is required, the UAS SHOULD return a 415 (Unsupported Media Type) > response even if the UAS supported the content type, the disposition type, > or both in a different context. Why isn't it a MUST rather than a SHOULD??? > Consequently, it is possible to receive a 415 (Unsupported Media Type) > response with an Accept header field containing all the content types used > in the request. > > If a UAS receives a request with a body part whose disposition type is not > compatible with the way the body part should be handled according to other > parts of the SIP message (e.g., a Refer-To header field with a Content-ID > URL pointing to a body part whose disposition type is 'session'), the UAS > SHOULD return a 415 (Unsupported Media Type) response. > > > 5. Guidelines to Authors of SIP Extensions > > These guidelines are intended for authors of SIP extensions that involve, > in some way, message bodies or body parts. > > > > > Camarillo Expires March 1, 2008 [Page 9] > Internet-Draft Message Body Handling in SIP August 2007 > > > This specification mandates support for 'multipart/mixed' and mandates. mumble. hmmm... > 'multipart/alternative' and describes how to handle 'multipart/ related' > [RFC2387] bodies. At present, there are no SIP extensions that use > different 'multipart' subtypes such as parallel [RFC2046] or digest > [RFC2046]. If such extensions were to be defined in the future, their > authors would need to make sure (e.g., by using an option-tag or by other > means) that entities receiving those 'multipart' subtypes were able to > process them. As stated earlier, UAs treat unknown 'multipart' subtypes as > 'multipart/mixed'. > > Body parts within a 'multipart/related' wrapper can reference each other. > Per [RFC2387], a UA processing a 'multipart/related' body processes it as a > compound object ignoring the disposition types of the body parts within > it. However, UAs that do not understand 'multipart/related' will treat it > as 'multipart/mixed'. These UAs will not be able to process the references > among the body parts and will process the body parts according to their > disposition type. > > When a SIP UA receives a header field or an optional body part it does not > understand, the UA ignores it. A header field or a body part carrying a > reference to another body part (e.g., a Content-ID URL) can influence the > way that body part is handled. If a header If this pertains to the earlier discussion about processing a reference, then there is no "can"; there is only "will". If this sentence is intended to convey some other implication, then I do not understand what it is. > field or a body part carrying a reference to a body part is not understood > and, thus, ignored by its recipient, the body part could be handled in an > unintended way. Therefore, authors of SIP "could"? If the body part is not understood then its handling is well-defined. While the generating of the part certainly did not "intend" that handling, they have to assume that a given recipient might not be able to process it and existing specification text says how to handle it. So, I am guessing that the text needs to say something like "In order to ensure that referenced body parts are processed properly, authors of SIP extensions..." > extensions that involve references to body parts need to make sure (e.g., > by using an option-tag or by other means) that entities processing those > extensions do not behave in unintended ways. I do not see how the above 4 paragraphs in this section offer 'guidelines' for extensions. > Additionally, authors of such extensions need to specify the acceptable > disposition types of the referenced body part and a default, mandatory to > support, content type per disposition type. > > As stated earlier, SIP extensions may also include 'multipart' MIME bodies > in responses. However, UACs receiving a response cannot CHANGE: ...bodies in responses. Hence, a response can be extremely complex and the client receiving the response might not be able to process the response correctly. Because UACs receiving a response cannot...requests), authors of SIP... > report errors to the UAS that generated the response (i.e., error responses > can only be generated for requests). Therefore, authors of SIP extensions > need to make sure that requests clearly indicate (e.g., by using an > option-tag or by other means) the capabilities of the UAC so that UASs can > decide what to include in their responses. > > > 6. Security Considerations > > TBD. > > > > > > > Camarillo Expires March 1, 2008 [Page 10] > Internet-Draft Message Body Handling in SIP August 2007 > > > 7. Acknowledgements > > The ideas in this document were discussed with Paul Kyzivat. Christer > Holmberg, Francois Audet, and Dan Wing provided comments on this document. > > > 8. IANA Considerations > > This document does not contain any IANA actions. > > > 9. References > > 9.1. Normative References > > [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail > Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, > November 1996. > > [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail > Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating > Presentation Information in Internet Messages: The Content-Disposition > Header Field", RFC 2183, August 1997. > > [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC > 2387, August 1998. > > [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource > Locators", RFC 2392, August 1998. > > [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., > Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", > RFC 3204, December 2001. > > [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., > Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session > Initiation Protocol", RFC 3261, June 2002. > > [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail > Extensions (MIME) Parameter", RFC 3459, January 2003. > > > > Camarillo Expires March 1, 2008 [Page 11] > Internet-Draft Message Body Handling in SIP August 2007 > > > [RFC3959] Camarillo, G., "The Early Session Disposition Type for the > Session Initiation Protocol (SIP)", RFC 3959, December 2004. > > [RFC4483] Burger, E., "A Mechanism for Content Indirection in Session > Initiation Protocol (SIP) Messages", RFC 4483, May 2006. > > 9.2. Informational References > > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., > Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", > RFC 2616, June 1999. > > [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and > D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant > Messaging", RFC 3428, December 2002. > > [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session > Description Protocol", RFC 4566, July 2006. > > [I-D.ietf-sip-multiple-refer] Camarillo, G., "Referring to Multiple > Resources in the Session Initiation Protocol (SIP)", > draft-ietf-sip-multiple-refer-01 (work in progress), January 2007. > > [I-D.ietf-mmusic-file-transfer-mech] Garcia-Martin, M., "A Session > Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", > draft-ietf-mmusic-file-transfer-mech-03 (work in progress), June 2007. > > > Author's Address > > Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland > > Email: Gonzalo.Camarillo@ericsson.com > > > > > > > > > Camarillo Expires March 1, 2008 [Page 12] > Internet-Draft Message Body Handling in SIP August 2007 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2007). > > This document is subject to the rights, licenses and restrictions contained > in BCP 78, and except as set forth therein, the authors retain all their > rights. > > This document and the information contained herein are provided on an "AS > IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS > SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE > INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES > OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in this > document or the extent to which any license under such rights might or > might not be available; nor does it represent that it has made any > independent effort to identify any such rights. Information on the > procedures with respect to rights in RFC documents can be found in BCP 78 > and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any assurances > of licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such proprietary > rights by implementers or users of this specification can be obtained from > the IETF on-line IPR repository at http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary rights > that may cover technology that may be required to implement this standard. > Please address the information to the IETF at ietf-ipr@ietf.org. > > > Acknowledgment > > Funding for the RFC Editor function is provided by the IETF Administrative > Support Activity (IASA). > > > > > > Camarillo Expires March 1, 2008 [Page 13] -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review From apps-review-bounces@ietf.org Fri Nov 16 10:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It39a-0007J5-EB; Fri, 16 Nov 2007 10:30:46 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1It39Z-0007HD-H9 for apps-review-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:30:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It39S-0007AN-O5; Fri, 16 Nov 2007 10:30:39 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It39P-0003cZ-Np; Fri, 16 Nov 2007 10:30:38 -0500 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 824574F159; Fri, 16 Nov 2007 10:30:34 -0500 (EST) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1It39N-0001bS-Vh; Fri, 16 Nov 2007 16:30:33 +0100 Date: Fri, 16 Nov 2007 16:30:33 +0100 From: Thomas Roessler To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net Message-ID: <20071116153033.GF28302@raktajino.does-not-exist.org> Mail-Followup-To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-04) X-Spam-Score: -4.0 (----) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: keyprov@ietf.org, apps-review@ietf.org Subject: [APPS-REVIEW] Review of draft-ietf-keyprov-dskpp-01 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org This is a review of draft-ietf-keyprov-dskpp-01. It occasionally strays into the PSKC draft; however, I haven't fully read that document. Specific observations on the HTTP binding: - In 12.2.4, the spec says "Persistent connections as defined in HTTP/1.1 are assumed, but not required." Taken literally, I don't know what "assumed, but not required" means. - The HTTP binding does not indicate whether it fully defines the behavior of the HTTP server that is appearing as part of the transactions, or whether the DSKPP server is identified by either a specific URI and/or Host. Please clarify that in the HTTP binding part. (4.3 -- and other places -- suggest that the DSKPP server is indeed identified by a specific URI, which would be just fine.) - In 12.2.4, instead of talking about "POST operations", maybe say "DSKPP requests are mapped to HTTP requests with the POST method". - For the 4-step protocol, it's probably worth calling out here how the different messages are bound together, as they may be transported through different connections. In particular, KeyProvServerHello is bound to the preceding KeyProvClientHello by being transmitted in the corresponding HTTP response; KeyProvServerHello MUST have a sessionId attribute, and the sesionId on the subsequent KeyProvClientNonce MUST be identical. KeyProServerFinished is then once again bound to the rest through HTTP (and possibly through a sessionID). - The HTTP binding does not cover content negotiation. I'd suggest: "HTTP requests MAY include an HTTP Accept header field. This header field SHOULD have the value application/vnd.ietf.keyprov.dskpp+xml. The Accept header MAY include additional content types defined by future versions of this protocol." (The server is allowed to downgrade [6.2.3], so if a future version uses a different content type, that should be in the client's request, along with the current one, *if* the client is willing to downgrade.) - The examples in 12.2.8 don't match the requirements from 12.2.3. - 12.2.7 is extremely fuzzy as to when the server-side initialization message may be sent. As long as that's indeed in response to a specific user request with the appropriate Accept header (e.g., to a specific DSKPP server URL), the use of the 200 code seems fine. However, please clarify that using a 200 code combined with the DSKPP content type is *not* an appropriate means to trigger protocol initialization during a browsing session where the user's request was directed to some other resource. (In that case, some 40x code might be much more appropriate.) - It's not clear how one-step DSKPP would work over HTTP. What kind of request does the client send to trigger that? If that isn't intended to run over HTTP, please clarify. - In 12.2.3, the spec says: "HTTP proxies MUST NOT cache responses carrying DSKPP messages. For this reason, the following holds:" That's a conformance requirement on HTTP proxies; don't do that. Instead: "In order to avoid caching of responses carrying DSKPP messages by proxies, the following holds:" (Also, note that POST invalidates cached entities.) - In 12.2.5, "If the type of a DSKPP request cannot be determined, the DSKPP responder MUST return a 400 response." What precisely is meant by "type cannot be determined"? (Example?) Reviewing BCP56, I would suspect that there might be slight differences of opinion on whether DSKPP should have a port and URI scheme of its own. However, given that the protocol binding (with the above clarifications) will be layered rather cleanly on HTTP, and won't confuse URI-based addressing, I fail to see the benefit of allocating a separate port and/or URI scheme. This binding looks like it is implementable on top of a conventional Web server, which would suggest sticking to port 80 and http (or port 443 and https). Beyond that point, I do not see any significant disagreements between the guidance in BCP56 and this draft. Various other observations while going through the document... - -00 included schema fragments in section 4.9. These are gone in the corresponding sections in -01, making review of the schema for consistency with the human-readable text significantly harder. I'd recommend resurrecting the schema fragements in future iterations of the draft for ease of review. While dropping the schema fragments, *any* human-readable documentation for types such as AbstractRequestType type has been lost. - Please say early on in the spec what name space prefixes are used in XML snippets throughout the document, and what they mean. - What's the order relation for the various Version attributes? Are they treated as decimal numbers, as strings, as a dot-separated pairs of two integers? Is "01.00" the same as "1.0"? - Trying to assemble the overall XML schema to validate some of the examples... * DSKPP imports the schema from PSKC, which in turn imports a schema for the urn:ietf:params:xml:ns:keyprov:logo namespace, which apparently isn't available anywhere. * The DSKPP and PSKC drafts use inconsistent namespaces for PSKC, urn:ietf:params:xml:ns:keyprov:container vs urn:ietf:params:xml:ns:keyprov:1.0:container * The DSKPP schema uses an extension construct like this one repeatedly (DeviceIdentifierDataType, KeyContainerType, PayloadType, KeyProvTriggerType): In conjunction with use of elementFormDefault="unqualified", that unfortunately leads to a non-deterministic content model, as DeviceId is not actually in the target namespace. One possible fix is to move away from elementFormDefault="unqualified". (PSKC uses "qualified" anyway.) - StatusCode is one out of a closed list of strings. For extensibility, it might be worth using URIs/URNs instead of text strings here, and defining StatusCode to be of type anyURI. - Same for PlatformType. - ProtocolVariantsType uses elements to identify supported protocol variants. I wonder if having an extension point in the schema for future variants might be useful. Also, why not use an URI-based extensibility pattern? - In 11.3.3, ds:KeyInfoType is used for Payloads, and "only those choices of the ds:KeyInfoType that identify a symmetric key are allowed". Does a ds:RetrievalMethod that points to a ds:KeyName elsewhere possibly identify a symmetric key? Please be clearer about which parts of ds:KeyInfo you use here. - Same in 11.2.3 for public keys. - IdentifierType is limited to a maximum 128 characters in the schema, yet that limitation is nowhere found in the normative text. - PSKC uses strings for algorithm identifiers, DSKPP uses URIs. Why the inconsistency? (I'd prefer URIs, for consistency with XML Signature, XML Encryption, and neighboring specs.) - In section 6.2.2, the normative text defines , , , as "a series of URIs..." -- that's actually not true, as each of these elements includes a sequence of container elements that in turn contain the URIs. Please be precise when describing XML structures. - In section 6.2.2.2, the text about 4 and 2 pass DSKPP seems confused: If the ProtocolVariantsType is not used, then the DSKPP server will proceed with ordinary 4-pass DSKPP. However, it does not support 4-pass DSKPP, then the server MUST find a suitable two-pass variant or else the protocol run will fail. I believe it's supposed to say "if no protocol variants are indicated, then the server will proceed with ordinary 4 pass, or maybe with 2 pass", or something like that. Please phrase this more clearly. (Incidentally, what does it mean that the *type* is not used?) - In 6.2.2.4, "An AuthenticationCode MAY or MAY NOT contain alphanumeric characters.." -- excuse me? - same section, "A DSKPP client MAY contain Authentication Data consisting of signed data of client Nonce with a client certificate's private key." I believe this is supposed to describe a public key signature of the client Nonce. - same section, "The element of ... have the following meaning" -- make that "elements" - same section, a lot of discussion that "certificate itself is typically sufficient"; "DeviceID, KeyID, and/or nonce provided in the element ougth to be sufficient to identify the requester". What's probably meant is that ClientID can be omitted if the requester can be identified otherwise. If so, please say that. - The security considerations are somewhat inconsistent in their attacker model. In some cases, a man in the middle is assumed to have the capability to bypass TLS protection (e.g., 14.2.2); in other sections transport security is presented as a solution to concerns about the integrity of protocol exchanges (e.g., 14.2.4). It would contribute to the clarity of the security considerations if there was a clear discussion of the assumptions beforehand, and a consistent use of attacker models later on. - While I've not worked this through fully, it appears that an active attacker can manipulate the SupportedKeyTypes and KeyType elements in the ClientHello and KeyProvServerHello messages, without the protocol failing, if both device and server support multiple key types with mutually interchangeable key material. That might lead to an inconsistent state, or possibly to the use of weak keys. It might be useful to use the negotiated algorithm value as input into the MAC derivation mechanism. - Finally, on yet another editorial note, the namespace in the schema and the one in the IANA considerations section are inconsistent. Regards, -- Thomas Roessler, W3C _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review From apps-review-bounces@ietf.org Fri Nov 16 10:47:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3Pq-0006Jg-6w; Fri, 16 Nov 2007 10:47:34 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1It3Po-0006G6-E9 for apps-review-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:47:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3Pn-0006EP-VF for apps-review@ietf.org; Fri, 16 Nov 2007 10:47:32 -0500 Received: from cyrus.dir.garr.it ([193.206.158.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3Pl-0003Sj-J4 for apps-review@ietf.org; Fri, 16 Nov 2007 10:47:31 -0500 Received: from [140.105.1.129] ([140.105.1.129]) (authenticated bits=0) by cyrus.dir.garr.it (8.13.8/8.13.7) with ESMTP id lAGFkxkb014880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2007 16:47:09 +0100 (CET) (envelope-from claudio.allocchio@garr.it) Date: Fri, 16 Nov 2007 16:46:34 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: apps-review@ietf.org, Eric Burger In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cyrus.dir.garr.it X-Spam-Score: 0.0 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 Cc: Subject: [APPS-REVIEW] RE: App Area review of draft-ietf-sipping-service-identification-00.txt X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org General Comments: The idea and the problem being addressed is described quite clearly in the "Introduction" section. However the Abstract itself seems to stress to much the "legal/fraud" bullet point, while the focus of the document indeed is elsewhere and more general. I would add a more coherent abstract instead of the current one. The term "user agent" is used in the document more as identifying the "hardware device", specifically when it states that multiple application can run within the same user agent, etc. This is not coherent with the normal definition of user agent, which corresponds to a specific application running inside a hardware device (the super-classical e-mail User Agent programme, running within a PC, mobile device, whatever...). It might lead to confusion. As a final general comment, the document itself is a Reccommendation more than a BCP in itself... are we sure this is the correct track to put it forward? Conclusion: IMHO ths document is useful, and should be pushed forward, even if it might sound "strange" a document whose aim is to prevent a potentially BAD practice... I really to not know if it whould be better to have this as somthing else than BCP... I would call it something in a category like "things you should not do". ;-) from now on, se inline... Best regards, and sorry for being a bit late in the revision! Claudio ------------- Detailed inline review: see below, notes labelled by ***, some portions of the draft omitted: SIPPING J. Rosenberg Internet-Draft Cisco Intended status: Best Current August 1, 2007 Practice Expires: February 2, 2008 Identification of Communications Services in the Session Initiation Protocol (SIP) draft-ietf-sipping-service-identification-00 <.. omitted ..> Abstract This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent. While seemingly simple, this process is quite complex, and when not addressed properly, can lead to fraud, interoperability problems, and stifling of innovation. *** see general comment above. Rosenberg Expires February 2, 2008 [Page 1] Internet-Draft Service ID August 2007 This document discusses these problems and makes recommendations on how to address them. <.. omitted ..> Rosenberg Expires February 2, 2008 [Page 2] Internet-Draft Service ID August 2007 1. Introduction The Session Initiation Protocol (SIP) [2] defines mechanisms for initiating and managing communications sessions between agents. SIP allows for a broad array of session types between agents. It can manage audio sessions, ranging from low bitrate voice-only up to multi-channel hi fidelity music. It can manage video sessions, ranging from small, "talking-head" style video chat, up to high definition multipoint video conferencing, to low bandwidth user- generated content, up to high definition movie and TV content. SIP endpoints can be anything - adaptors that convert an old analog telephone to Voice over IP (VoIP), dedicated hardphones, fancy hardphones with rich displays and user entry capabilities, softphones on a PC, buddylist and presence applications on a PC, dedicated videoconferencing peripherals, and speakerphones. This breadth of applicability is SIPs greatest asset, but it also introduces numerous challenges. One of these is that, when an endpoint generates a SIP INVITE for a session, or receives one, that session can potentially be within the context of any number of different use cases and endpoint types. For example, a SIP INVITE with a single audio stream could represent a Push-To-Talk session between mobile devices, a VoIP session between softphones, or audio- based access to stored content on a server. These differing use cases have driven implementors and system designers to seek techniques for service identification. Service identification is the process of determining and/or signaling the specific use case that is driving the signaling being generated by a user agent. At first glance, this seems harmless and easy enough. It is tempting to define a new header, "Service-ID", for example, and have a user agent populate it with any number of well-known tokens which define what the service is. This information could then be consumed for any number of purposes. *** it is unclear at this point if the idea of the new header here is being anyhow suggested, depracted, or an alternate better solution should be stanrdised. I guess it should make such a statement, already at this point, to clarify. However, as this document will demonstrate, service identification is a very complex and difficult process, and can very easily lead to fraud, systemic interoperability failures, and a complete stifling of the innovation that SIP was meant to achieve. Section 3 begins by defining a service and the service identification problem. Section 4 gives some concrete examples of services and why they can be challenging to identify. Section 5 explores the ways in which a service identification can be utilized within a network. Next, Section 6 discusses the key architectural principles of service identification, and how explicit service identifiers can lead to fraud, interoperability failures, and stifling of service innovation. Rosenberg Expires February 2, 2008 [Page 3] Internet-Draft Service ID August 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 3. Services and Service Identification The problem of identifying services within SIP is not a new one. The problem has been considered extensively in the context of presence. In particular, the presence data model for SIP [3] defines the concept of a service as one of the core notions that presence describes. Services are described in Section 3.3 of RFC 4479, which has this to say on the topic: *** as a general procedural suggestion, I would avoid quoting full sections of existing other documents, as they may be updated, obsoleted, etc, creating corss reference problems more complex than needed if full quoting is used. Replacing the "included" session with a reference and just a few significant senteces makes it better. And, people redint this BCP shall have no problems in reading the full original section, or updates, themselves. 3.3. Service Each presentity has access to a number of services. Each of these represents a point of reachability for communications that can be used to interact with the user. Examples of services are telephony (that is, traditional circuit-based telephone service), push-to-talk, instant messaging, Short Message Service (SMS), and Multimedia Message Service (MMS). *** for example, the definition of "presentity" is missing here, forcing the cautious readed to grab and read the original specification anyhow :-) It is difficult to give a precise definition for service. One reasonable approach is to model each software or hardware agent in the system as a service. If a user starts a softphone application on <.. omitted ..> Essentially, the service is the user-visible use case that is driving the behavior of the user-agents and servers in the SIP network. Being user-visible means that there is a difference in user experience between two services that are different. That user experience can be part of the call, or outside of the call. Within a call, the user experience can be based on different media types (an audio call vs. a video chat), different content within a particular media type (stored content, such as a movie or TV session), different devices (a wireless device for "telephony" vs. a PC application for "voice-chat"), different user interfaces (a buddy list view of voice on a PC application vs. a software emulation of a hard phone), different communities that can be accessed (voice chat with other users that have the same voice chat client, vs. voice communications with any endpoint on the PSTN), or different applications that are invoked by the user (manually selecting a push-to-talk application from a wireless phone vs. a telephony application). Outside of a call, the difference in user experience can be a billing one (cheaper for one service than other), a notification feature for one and not another (for example, an IM that gets sent whenever a user makes a Rosenberg Expires February 2, 2008 [Page 5] Internet-Draft Service ID August 2007 call), and so on. In some cases, there is very little difference in the underlying technology that will support two different services, and in other cases, there are big differences. However, for purposes of this discussion, the key definition is that two services are distinct when there is a perceived difference by the user in the two services. *** the whole above descriptive section is mabe even too long. The concept is made clear in the last above sentence "However... in the two services", hence I suggest shrinking the previous descripive text. This leads naturally to the desire to perform service identification. Service identification is defined as the process of (1) determination of the underlying service which is driving a particular signaling exchange, (2) associating that service with some kind of moniker, and (3) attaching that moniker to a signaling message (typically a SIP INVITE), and then utilizing it for various purposes within the network. Service identification can be done in the endpoints, in which case the UA would insert the moniker directly into the signaling message based on its awareness of the service. Or, it can be done within a proxy in the network, based on inspection of the SIP message, or based on hints placed into the message by the user. 4. Example Services It is very useful to consider several example services, especially ones that appear difficult to differentiate from each other. 4.1. IPTV vs. Multimedia IP Television (IPTV) is the usage of IP networks to access traditional television content, such as movies and shows. SIP can be utilized to establish a session to a media server in a network, which then serves up multimedia content and streams it as an audio and video stream towards the client. Whether SIP is ideal for IPTV is, in itself, a good question. However, such a discussion is outside the scope of this document. Consider multimedia conferencing. The user accesses a voice and video conference at a conference server. The user might join in listen-only mode, in which case the user receives audio and video streams, but does not send. These two services - IPTV and multimedia conferencing, clearly appear as different services. They have different user experiences and applications. A user is unlikely to ever be confused about whether a session is IPTV or multimedia conferencing. Indeed, they are likely to have different software applications or endpoints for the two services. *** make it MORE clear that the multimedia conference you're talking about is the ONE WAY unidirectional "listening only" version of it. It might be more appropriate to call it "multimedia conference listening", or something similar for the purpouse of this example. Rosenberg Expires February 2, 2008 [Page 6] Internet-Draft Service ID August 2007 However, these two services look remarkably alike based on the signaling. Both utilize audio and video. Both could utilize the same codecs. Both are unidirectional streams (from a server in the network to the client). Thus, it would appear on the surface that there is no way to differentiate them, based on inspection of the signaling alone. 4.2. Gaming vs. Voice Chat Consider an interactive game, played between two users from their mobile devices. The game involves the users sending each other game moves, using a messaging channel, in addition to voice. In another service, users have a voice and IM chat conversation using a buddy list application on their PC. In both services, there are two media streams - audio and messaging. The audio uses the same codecs. Both use the Message Session Relay Protocol (MSRP) [5]. In both cases, the caller would send an INVITE to the AOR of the target user. However, these represent fairly different services, in terms of user experience. *** expand AOR acronym here, as it is the first occurence of it. <.. omitted ..> 5. Using Service Identification It is important to understand what the service identity would be utilized for, if known. The discussions in Section 4 give some hints Rosenberg Expires February 2, 2008 [Page 7] Internet-Draft Service ID August 2007 to the possible usages. Here, we explicitly discuss them. 5.1. Application Invocation in the User Agent In some of the examples above, there were multiple software applications running within a single user agent. When an incoming *** see "User Agent" term use note I made inside the General Comments above. *** is this sections exp;icitly suggesting the creation of the UI given in the figure below? It is not crstal clear... or it is just using the idea as a basis for discussiong its consequences if used? I would clarify this in the begining of it. INVITE or MESSAGE arrives, it must be delivered to the appropriate application software. When each service is bound to a distinct software application, it would seem that the service identity is needed to dispatch the message to the appropriate piece of software. This is shown in Figure 2. +---------------------------------+ | | | +-------------+ +-------------+ | | | UI | | UI | | | +-------------+ +-------------+ | | +-------------+ +-------------+ | | | | | | | | | Service 1 | | Service 2 | | | | | | | | | +-------------+ +-------------+ | | +-----------------------------+ | | | | | | | SIP | | | | Layer | | | | | | | +-----------------------------+ | | | +---------------------------------+ Physical Device Figure 2 <.. omitted ..> 6. Key Principles of Service Identification In this section, we describe some of the key principles of performing service identification. 6.1. Services are a By-Product of Signaling *** this section clearly states principles and reasons behind them. This is where the reference in the introduction should point for clarification of the suggestion that service-id is suggested or not. This is ultimately an expression of the principle of DWIM vs. DWIS (Do-What-I-Mean vs. Do-What-I-Say). Explicit signaling is DWIS - the user is asking for a service by invoking the signaling that results in the desired effect. A service identifier is DWIM - an unspecific request for something that is ill-defined and non-interoperable. *** true, please stress this also in introduction. 6.2. Perils of Explicit Identifiers *** this section is the core of the motivation of the reccomendation in the following chapter. I would name it consequently, or make it clearer its role in the title. 7. Recommendations From these principles, several recommendations can be made: o Systems needing to perform service identification must examine existing signaling constructs to identify the service based on fields that exist within the signaling message already. o If it appears that the signaling currently defined in standards is not sufficient to identify the service, it may be due to lack of sufficient signaling to convey what is needed, and new standards work should be undertaken to fill this gap. o The usage of an explicit service identifier does make sense as a way to cache a decision made by a network element, for usage by another network element within the same domain. However, service identifiers are fundamentally useful within a particular domain, and any such header must be stripped at a network boundary. *** ok see above. Rosenberg Expires February 2, 2008 [Page 19] Internet-Draft Service ID August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Rosenberg Expires February 2, 2008 [Page 20] _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review From apps-review-bounces@ietf.org Fri Nov 16 11:06:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3iT-0003dd-Er; Fri, 16 Nov 2007 11:06:49 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1It3iR-0003cJ-QJ for apps-review-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:06:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3iR-0003bp-FA; Fri, 16 Nov 2007 11:06:47 -0500 Received: from homer.w3.org ([128.30.52.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3iR-0005dN-01; Fri, 16 Nov 2007 11:06:47 -0500 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D9D1B4F159; Fri, 16 Nov 2007 11:06:45 -0500 (EST) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1It3iP-0001f9-BM; Fri, 16 Nov 2007 17:06:45 +0100 Date: Fri, 16 Nov 2007 17:06:45 +0100 From: Thomas Roessler To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org Message-ID: <20071116160645.GH28302@raktajino.does-not-exist.org> Mail-Followup-To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org References: <20071116153033.GF28302@raktajino.does-not-exist.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071116153033.GF28302@raktajino.does-not-exist.org> User-Agent: Mutt/1.5.17 (2007-11-04) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [APPS-REVIEW] Re: Review of draft-ietf-keyprov-dskpp-01 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On 2007-11-16 16:30:33 +0100, Thomas Roessler wrote: > Reviewing BCP56, I would suspect that there might be slight > differences of opinion on whether DSKPP should have a port and URI > scheme of its own. However, given that the protocol binding (with > the above clarifications) will be layered rather cleanly on HTTP, > and won't confuse URI-based addressing, I fail to see the benefit of > allocating a separate port and/or URI scheme. This binding looks > like it is implementable on top of a conventional Web server, which > would suggest sticking to port 80 and http (or port 443 and https). > Beyond that point, I do not see any significant disagreements > between the guidance in BCP56 and this draft. ... and reviewing the old discussion on apps-review (which I meant to do before sending the review, but didn't), the disagreement might in fact be not so slight. So, apologies. See in particular: http://www1.ietf.org/mail-archive/web/apps-review/current/msg00085.html So, there are a number of criteria on the table here: - BCP56 mainly talks about expected server implementation and network filtering. In terms of server implementation, DSKPP sounds as though it could be implemented on top of an existing HTTP server; from my review, the layering is reasonably clean. Yes, there is separate code, but not in a way that's significantly different from any Web app. The possible arguments in favor of new methods don't sound like they apply (POST should be just fine), which leaves questions about network administrators and "different data sets" as the remaining ones. I don't understand what the "different data sets" criterion is even supposed to mean, and can't speak to the network administrators. - In Chris' message (URL above), he writes: > Unless the primary client for your protocol is a web browser, I > would strongly encourage registering a separate port. There is indeed some indication in the specification that the protocol might at the very least be triggered through a traditional Web browser. Besides that, any exchanges beyond a possible trigger message seem to involve dereferencing a URI with POST as the method anyway, so the port is configurable at that point, if the deployer so desires. That, to me, suggests strongly that Chris' argument doesn't really apply to the spec at hand. To the more general statement that "At this point it's inevitable we'll end up with intrusive firewalls on port 80 that will break anything beyond stock browser-based HTTP", I'd notice that POST with some XML content type and some XML content is totally within the realm of "stock browser-based HTTP" today. http://www.w3.org/TR/XMLHttpRequest/ So, in summary, I don't see convincing reasons to urge the DSKPP group to move this away from port 80. Cheers, -- Thomas Roessler, W3C _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review From apps-review-bounces@ietf.org Fri Nov 30 20:16:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyGy1-00061A-Tk; Fri, 30 Nov 2007 20:16:25 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IyGy0-00060y-Ug for apps-review-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 20:16:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyGxu-0005zn-Oy for apps-review@ietf.org; Fri, 30 Nov 2007 20:16:18 -0500 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyGxu-0004WV-A7 for apps-review@ietf.org; Fri, 30 Nov 2007 20:16:18 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB11GEU9013628 for ; Fri, 30 Nov 2007 17:16:14 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB11GC6N020667 for ; Fri, 30 Nov 2007 17:16:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 30 Nov 2007 17:16:11 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminders for Reviewers Thread-Index: Acgzt8J+S02z10cSRfS2hVDcTm8VSg== From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [APPS-REVIEW] Reminders for Reviewers X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org PLEASE remember to copy your reviews to the relevant draft authors when you post them to the apps-review list. Thanks. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review