Picon
Picon
Favicon

RE: ETSI TISPAN interest in tv:URI

All,

The issue of identification of television channels for IPTV Presence has
been discssed at the ETSI TISPAN 14ter and 15 Plenary meetings. This has
lead to the start of a new Work Item in Working Group WG4. 

The new Work Item WI 4014 is titled "Guidelines on TV URI use for the
identification of television channels", see
http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=27318.

The subject of IPTV Presence itself ("my buddies being able to see which
TV channel I am watching") will be documented in the protocol document
TS 183 063 "IMS-based IPTV stage 3 specification", see
http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=26367

TISPAN WG4 (identifiers) has allocated a session in next TISPAN meeting
dedicated to "Guidelines on TV URI use for the identification of
television channels"". The meeting details are as follows, see
http://webapp.etsi.org/MeetingCalendar/MeetingDetails.asp?mid=11493.

Meeting: TISPAN4-TISPAN WG4 Ad Hoc 
Location: ETSI Headquarters, Sophia Antipolis
Dates: 26-30 November 2007

With this email, I would like to invite interested parties to
participate and/or contribute to this ETSI TISPAN WG4 work.

Best regards,

Oskar 
(Continue reading)

John C Klensin | 2 Nov 20:24

IDNAbis documents

Hi.

Two new documents, draft-klensin-idnabis-issues-03 and
draft-klensin-idnabis-protocol-00 have been posted  The first
has been announced, the second should follow soon.

These are the first versions of the IDNAbis document set that
separate the protocol specification from the theory and
rationale.   I suggest that anyone interested in IDNA examine
them as closely as possible.

     john

Lisa Dusseault | 6 Nov 02:40
Favicon

Lisa's Apps area activity for October 2007

Notes: 
 - ATOMPUB working group closed
 - HTTP working group chartered
 - See you in Vancouver -- Accepting Apparea meeting topics 

Document Status and Progress

Active Documents: my action
 - draft-sjdcox-cgi-urn (None): I need to review
 - draft-adolf-dvb-urn (Informational): I need to do a writeup -- no document shepherd

Stalled, in review, waiting on other:
 - draft-ietf-sieve-notify: waiting on author response to AD review
 - draft-ietf-sieve-notify-mailto: waiting on author response to AD review
 - draft-ietf-sieve-notify-xmpp:  waiting on author response to AD review
 - draft-goodwin-iso-urn (Informational): in IETF Last Call
 - draft-snell-atompub-bidi (Proposed Standard): author waiting on some implementation feedback
 - draft-creed-ogc-urn (Informational): in IETF Last Call
 - draft-wilde-sms-uri (Proposed Standard): in IETF Last Call
 - draft-ietf-sieve-body (Proposed Standard): Waiting on revised ID to deal with gen-art feedback
 - draft-mealling-epc-urn (Informational): Ready for IESG Evaluation
 - draft-ietf-imapext-sort (Proposed Standard) : waiting for authors to revise or decide it's ready
 - draft-montemurro-gsma-imei-urn (Experimental): Waiting for authors to deal with early feedback

Finished Processing -- RFC Ed queue and new RFCs
 - draft-saintandre-rfc4622bis (Proposed Standard)
 - draft-crocker-rfc4234bis (Standard)
 - draft-ietf-sieve-3028bis (Proposed Standard)
 RFC5051 -- i;unicode-casemap - Simple Unicode Collation Algorithm
 RFC5023 -- The Atom Publishing Protocol

WG Status
 - SIEVE waiting for final documents to go through evaluation, IETF last call, etc.
 - IMAPEXT stalled waiting for i18n work to complete
 - ATOMPUB closed
 - CALSIFY quiet in last month
 - USEFOR stalled on single WG deliverable
 - HTTP just started up 

Lisa 

Favicon

FW: [YANG] YANG draft


I apologize for cross-posting. 

Dan

-----Original Message-----
From: Martin Bjorklund [mailto:mbj <at> tail-f.com] 
Sent: Wednesday, November 07, 2007 11:05 PM
To: yang <at> ietf.org
Subject: [YANG] YANG draft

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : YANG - A data modeling language for NETCONF
	Author(s)       : M. Bjorklund
	Filename        : draft-bjorklund-netconf-yang-00.txt
	Pages           : 147
	Date            : 2007-11-07

YANG is a data modeling language used to model configuration and state
data manipulated by the NETCONF protocol, NETCONF remote procedure
calls, and NETCONF notifications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt

/martin

Lisa Dusseault | 9 Nov 19:55
Favicon

Usefulness of WSDL


I see WSDL proposed for some spec in the IETF every so often but nobody's ever explained to me what it solves.  James Snell who has more experience than me in the matter wrote:

"Those who are familiar with my history with IBM should know that I was once a *major* proponent of the WS-* approach. I was one of the original members of the IBM Emerging Technologies Toolkit team, I wrote so many articles on the subject during my first year with IBM that I was able to pay a down payment on my house without touching a dime of savings or regular paycheck, and I was involved in most of the internal efforts to design and prototype nearly all of the WS-* specifications. However, over the last two years I haven’t written a single line of code that has anything to do with WS-*. The reason for this change is simple: when I was working on WS-*, I never once worked on an application that solved a real business need. Everything I wrote back then were demos. Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit."

Anybody got counter-arguments or is this a reasonable indictment?

Lisa

James M Snell | 9 Nov 20:06
Picon

Re: Usefulness of WSDL

Just as a point of clarification: I'm not saying that WSDL is not useful
in general; I'm saying that in my personal experience I've never had any
reason to ever use it in a real-world application. :-)

- James

Lisa Dusseault wrote:
> 
> I see WSDL proposed for some spec in the IETF every so often but
> nobody's ever explained to me what it solves.  James Snell who has more
> experience than me in the matter wrote:
> 
> "Those who are familiar with my history with IBM should know that I was
> once a *major* proponent of the WS-* approach. I was one of the original
> members of the IBM Emerging Technologies Toolkit team, I wrote so many
> articles on the subject during my first year with IBM that I was able to
> pay a down payment on my house without touching a dime of savings or
> regular paycheck, and I was involved in most of the internal efforts to
> design and prototype nearly all of the WS-* specifications. However,
> over the last two years I haven’t written a single line of code that has
> anything to do with WS-*. The reason for this change is simple: when I
> was working on WS-*, I never once worked on an application that solved a
> real business need. Everything I wrote back then were demos. Now that
> I’m working for IBM’s WebAhead group, building and supporting
> applications that are being used by tens of thousands of my fellow
> IBMers, I haven’t come across a single use case where WS-* would be a
> suitable fit."
> 
> Anybody got counter-arguments or is this a reasonable indictment?
> 
> Lisa
> 
> [from James' blog: http://www.snellspace.com/wp/?p=798]

Mark Baker | 9 Nov 21:26
Picon
Favicon
Gravatar

Re: Usefulness of WSDL

On 11/9/07, Lisa Dusseault <ldusseault <at> commerce.net> wrote:
>
>
> I see WSDL proposed for some spec in the IETF every so often but nobody's
> ever explained to me what it solves.  James Snell who has more experience
> than me in the matter wrote:
>
> "Those who are familiar with my history with IBM should know that I was once
> a *major* proponent of the WS-* approach. I was one of the original members
> of the IBM Emerging Technologies Toolkit team, I wrote so many articles on
> the subject during my first year with IBM that I was able to pay a down
> payment on my house without touching a dime of savings or regular paycheck,
> and I was involved in most of the internal efforts to design and prototype
> nearly all of the WS-* specifications. However, over the last two years I
> haven't written a single line of code that has anything to do with WS-*. The
> reason for this change is simple: when I was working on WS-*, I never once
> worked on an application that solved a real business need. Everything I
> wrote back then were demos. Now that I'm working for IBM's WebAhead group,
> building and supporting applications that are being used by tens of
> thousands of my fellow IBMers, I haven't come across a single use case where
> WS-* would be a suitable fit."
>
> Anybody got counter-arguments or is this a reasonable indictment?

Nope, sounds about right to me.  IMO, the whole notion of
service-specific interfaces - the reason WSDL exists - is an anethema
to Internet scale and so has no place in the IETF.  It also encourages
bad practice around exposing implementation details, such as the
current schema support by the device (because we all know, those never
change over time 8-).

That said, if some spec author wants to use it, I don't see any need
to prevent them from doing so, so long as the emphasis of the spec is
on the protocol.

Mark.
--

-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

RL 'Bob' Morgan | 9 Nov 22:33
Favicon

Re: Usefulness of WSDL


> I see WSDL proposed for some spec in the IETF every so often but 
> nobody's ever explained to me what it solves.

The motivations for Interface Definition Languages (IDLs), of which WSDL 
is an example, and of Remote Procedure Call (RPC) systems, of which IDLs 
are a component (and of which WS-* is an example), are straightforward. 
Among other places they are described in RFCs 1057 and 1831, which 
document Sun's ONC RPC (1831 is standards-track even).  The seminal paper, 
as mentioned in 1831, is

   Birrell, A. D.  & Nelson, B. J., "Implementing Remote Procedure
   Calls", XEROX CSL-83-7, October 1983.

for which a cursory search doesn't reveal an online instance.  (Some might 
flame at calling WS-* "RPC", so OK, substitute "RPC-like distributed 
computing system" instead.)

The idea is that protocols are hard to write, and software implementing 
protocols is hard to write.  So an RPC system creates a meta-protocol; a 
concrete protocol to do real operations is created by writing an interface 
definition in an IDL.  The IDL serves as generator for both a protocol 
spec and an API spec; the IDL is fed into a language-specific stub 
generator which produces libraries for use in that language for that 
interface (ie, that protocol).  The programmer just uses those libraries 
like she would any other libraries when implementing a system.  Voila, the 
pain of writing protocol implementations, and protocols, vanishes.

This argument has been so compelling that dozens (maybe hundreds) of RPC 
systems have been invented, and many widely deployed, over the years. 
Each promises to solve the problems that have led to the previous ones not 
meeting the hype of their promoters.  And of course the gap between hype 
and adoption has led to some of them being among the highest-profile 
computing failures (see "DCE"), at least in popular opinion.

I think the story has remained largely the same for the last 25 years or 
so.  Using an RPC system is undeniably better than the usual system 
integration alternative of making up a new protocol from scratch, which 
anyone doing system integration knows leads to appalling protocol 
interfaces on systems of all kinds.  But RPC systems never seem to escape 
this niche of home-grown interfaces for a small purpose with a few 
consumers.  Probably there are lots of reasons why this has been so.  I'd 
guess among the most important is that IDL toolkits inevitably become 
language- and vendor-centric, so the theoretical cross-platform agility 
and interop doesn't happen in real life.  So people with real scalable 
distributed systems work to do focus on real protocols and accept the 
burden of writing implementations of them more or less from scratch (often 
these days based on HTTP+REST).  (Obviously there are many perspectives 
and counterexamples, it's a big Internet.)

Given that Internet protocols specified in RFCs are presumably intended 
for those widely distributed and widely implemented cases, it seems like 
RPC/IDL technology, including WS-*/WSDL, is generally inappropriate. 
Obviously there have been exceptions, as RFCs 1831-3 and 3530 demonstrate.

  - RL "Bob"

Tim Bray | 11 Nov 22:06
Favicon
Gravatar

Re: Usefulness of WSDL

Lisa, you might it useful to pull a copy of the WSDL spec and invest a
half-hour in just looking at it.  It's really hard to understand, and
my feeling is that it's an extremely poor piece of design.

I can remember I was once speaking at a big Java conference, maybe 600
people in audience; I asked for a show of hands as to who was using
WSDL.  A large majority of hands went up.  Then I asked how many
thought they actually understood it.  Maybe 2 or 3 hands.  How many
liked it?  Another couple of hands.

Based on experience with WS-*, I suspect that in general any IETF spec
that requires the use of WSDL will be expensive to implement and
fragile in deployment.   Among other things, a spec that's regarded as
difficult to understand should be avoided if there's a plausible
alternative.  -Tim

Leif Johansson | 12 Nov 12:12
Picon
Picon
Gravatar

Re: Usefulness of WSDL


These days WS-* is something everyone loves to hate (and often for
good reason). In the case of WSDL I think its good to remember that
WSDL is one of the very few WS* technologies that has been widely
implemented - people do actually use WSDL from perl-based SOAP-
stacks to lookup and call java-based services etc.

As for how much developers _really_ understand technology, I suspect
one would get similar answers as Tim got if one were to ask a set of
programmers about just about any set of technologies for which there
is good tooling available. Those programmers probably was thinking more
about the quality of the tooling than about the quality of the under-
lying technology.

I think it may be interesting to ask why WSDL turns up in IETF specs
but not (say) WS-Policy or WS-ReliableMessaging. My guess would be
that in many cases solutions which started out as simple systems-
integration RPCs (ct-kip-ws may be an example) have grown into
protocols in the sense that they are implemented by multiple vendors etc.

          Cheers Leif


Gmane